maemo.org Bugzilla – Full Text Bug Listing
|Summary:||Scratchbox makes building extensions to target Perl, Python etc awkward|
|Product:||[Maemo Official Platform] Development platform||Reporter:||Tony Green <home>|
|Status:||RESOLVED WONTFIX||QA Contact:||dev-platform-general-bugs|
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: *** [perperl_backend] Error 1 make: 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?
Re-assigned to correct person. Mika: Could you investigate this issue?
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...
Mika: ping - still around?
Soumya: Can you please take a look at this and comment? Tony: Any luck with Diablo?
(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.
Hmm, that was 4.0. Would be nice to see whether this has improved for 4.1.
(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.
(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.
Soumya, any news here?
(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...)
WONTFIX as per last comment.