Bug 1954 – Scratchbox makes building extensions to target Perl, Python etc awkward

Bug 1954 - Scratchbox makes building extensions to target Perl, Python etc awkward


Summary:	Scratchbox makes building extensions to target Perl, Python etc awkward

Status:	RESOLVED WONTFIX

Product:	Development platform
Component:	general
Version:	4.1 (4.2008.23-14)
Platform:	ARM Linux

Importance:	Medium normal (vote)
Target Milestone:	---
Assigned To:	Soumya
QA Contact:	dev-platform-general-bugs

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree

Reported:	2007-09-01 17:31 UTC by Tony Green
Modified:	2009-01-13 15:35 UTC (History)
CC List:	2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note

You need to log in before you can comment on or make changes to this bug.

Description Tony Green (reporter) 2007-09-01 17:31:01 UTC

I have been trying to build Persistent Perl in the development environment (3.2
Bora) but compilation fails with error messages saying that
/scratchbox/tools/lib/perl5/5.8.4/i686-linux-thread-multi/auto/DynaLoader/DynaLoader.a
has a problem due reading symbols.

EXPECTED OUTCOME:
Program should compile successfully.

ACTUAL OUTCOME:
The following messages:
gcc  -o perperl_backend perperl_backend_main.o perperl_perl.o perperl_util.o
perperl_sig.o perperl_frontend.o perperl_backend.o perperl_file.o
perperl_slot.o perperl_poll.o perperl_ipc.o perperl_group.o perperl_script.o
perperl_opt.o perperl_optdefs.o xsinit.o  -Wl,-E  -L/usr/local/lib
/scratchbox/tools/lib/perl5/5.8.4/i686-linux-thread-multi/auto/DynaLoader/DynaLoader.a
-L/scratchbox/tools/lib/perl5/5.8.4/i686-linux-thread-multi/CORE -lperl -lnsl
-ldl -lm -lcrypt -lutil -lpthread -lc
/scratchbox/compilers/cs2005q3.2-glibc-arm/lib/gcc/arm-none-linux-gnueabi/3.4.4/../../../../arm-none-linux-gnueabi/bin/ld:
/scratchbox/tools/lib/perl5/5.8.4/i686-linux-thread-multi/auto/DynaLoader/DynaLoader.a(DynaLoader.o):
Relocations in generic ELF (EM: 3)
/scratchbox/tools/lib/perl5/5.8.4/i686-linux-thread-multi/auto/DynaLoader/DynaLoader.a:
could not read symbols: File in wrong format
collect2: ld returned 1 exit status
make[1]: *** [perperl_backend] Error 1
make[1]: Leaving directory `/home/tony/PersistentPerl-2.22/perperl_backend'
make: *** [subdirs] Error 2



STEPS TO REPRODUCE THE PROBLEM:
Download source from http://daemoninc.com/PersistentPerl/
tar -zxvf PersistentPerl-2.22.tar.gz
Activate SDK_ARMEL target
cd ~/PersistentPerl-2.22
perl Makefile.PL
make

OTHER COMMENTS:
I would have taken this to be a bug with Persistent Perl, but I have also tried
to build the Apache mod_perl module and this fails in exactly the same way,
which leads me to believe that the problem is with the SDK.

Attempting to build this with SDK_X86 active works fine. I suspect this must
mean that ONLY X86 files are available.
If I issue:
find / -name "DynaLoader.?"
with either target active, it finds only one file:
/scratchbox/tools/lib/perl5/5.8.4/i686-linux-thread-multi/auto/DynaLoader/DynaLoader.a
Possibly there should be an ARM directory as well?

Comment 1 Jake Kunnari 2007-09-20 12:28:19 UTC

Re-assigned to correct person. Mika: Could you investigate this issue?

Comment 2 Tony Green (reporter) 2007-09-29 16:20:27 UTC

I've just had a go at installing the new 4.0 Beta development environment.
maemo-scratchbox-install_4.0beta.sh installs the basic Scratchbox which
includes DynaLoader in the i686 directory structure but again doesn't have it
in the ARML structure. So it appears that the problem is with Scratchbox rather
than the Maemo-specific installation.

...does mean that my thought that using the new release would help failed, but
that's life...

Comment 3 Andre Klapper maemo.org

2008-07-18 15:52:54 UTC

Mika: ping - still around?

Comment 4 Andre Klapper maemo.org

2008-07-29 17:53:13 UTC

Soumya: Can you please take a look at this and comment?

Tony: Any luck with Diablo?

Comment 5 Tony Green (reporter) 2008-07-29 22:51:20 UTC

(In reply to comment #4)

> Tony: Any luck with Diablo?
> 

I haven't tried anything with this recently. I managed to get my most important
modules (dbd-mysql and dbi) to build with a workaround I found somewhere which
involved setting an environment variable: SBOX_REDIRECT_IGNORE=/usr/bin/perl

I'm not sure which version of Scratchbox I last tried; my development box isn't
on my network at the moment. From what I can make out from the backups, I
installed it on January 28th this year, so it was whatever version was
available them.

Comment 6 Andre Klapper maemo.org

2008-08-08 17:31:06 UTC

Hmm, that was 4.0. Would be nice to see whether this has improved for 4.1.

Comment 7 Tony Green (reporter) 2008-08-08 17:42:00 UTC

(In reply to comment #6)
> Hmm, that was 4.0. Would be nice to see whether this has improved for 4.1.
> 

I'll try to find time to install 4.1 and have another try in the next few days.

Comment 8 Tony Green (reporter) 2008-08-28 17:49:57 UTC

(In reply to comment #6)
> Hmm, that was 4.0. Would be nice to see whether this has improved for 4.1.
> 

Still the same with 4.1, I'm afraid, Andre.

Comment 9 Andre Klapper maemo.org

2008-08-29 06:03:06 UTC

Soumya, any news here?

Comment 10 Eero Tamminen nokia

2008-09-01 15:08:18 UTC

(In reply to comment #0)
> Attempting to build this with SDK_X86 active works fine. I suspect this
> must mean that ONLY X86 files are available.

If you were building x86 *target* binaries instead of x86 host binaries,
it most likely got then also something wrong.


Building extensions for target (arm) binaries (for things like perl,
python etc) which are already included as host (x86) binaries is
a known (but not very well documented) Scratchbox issue.

The general reason why these binaries are provided in Sbox as host binaries
is build speed i.e. basically it's a Scratchbox use performance optimization.

The SBOX_REDIRECT_IGNORE (documented in /scratchbox/doc/variables.txt)
is one way to work around the issue for a specific package *if* it calls the
binary always with path.  If developer needs to work around this with sources
which call the binaries without a path, it's best just to rename/remove
the corresponding Scratcbox host binary.  Some people even do "native"
compilation in System Qemu (e.g. with Mamona).


(In reply to comment #6)
> Hmm, that was 4.0. Would be nice to see whether this has improved for 4.1.

There isn't any reasonable way in which this could be solved except by
removing these tools from from Scratchbox.  However, especially in the
case of Perl then build of many other things may fail in Scratchbox if
the target rootstrap doesn't include (an ARM version) of Perl because
many things expect the presence of Perl (it's POSIX standard utility etc).
And like with other host tools, the builds will be slower without them.

I would just mark this as WONTFIX.

(I'm not sure whether SB2 would make this any easier.  Controlling
the visibility of different host tools is more finegrained in it...)

Comment 11 Andre Klapper maemo.org

2009-01-13 15:35:25 UTC

WONTFIX as per last comment.