When trying to xmerge for arm-softfloat-linux-uclibc I found out that during the build process the build system tried to run a target binary. Of course, that fails. xmerge -v media-libs/libart_lgpl These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] media-libs/libart_lgpl-2.3.19-r1 to /usr/arm-softfloat-linux-uclibc/ USE="-debug" 0 kB Total: 1 package (1 new), Size of downloads: 0 kB >>> Verifying ebuild Manifests... >>> Emerging (1 of 1) media-libs/libart_lgpl-2.3.19-r1 to /usr/arm-softfloat-linux-uclibc/ * libart_lgpl-2.3.19.tar.bz2 RMD160 ;-) ... [ ok ] * libart_lgpl-2.3.19.tar.bz2 SHA1 ;-) ... [ ok ] * libart_lgpl-2.3.19.tar.bz2 SHA256 ;-) ... [ ok ] * libart_lgpl-2.3.19.tar.bz2 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * checking libart_lgpl-2.3.19.tar.bz2 ;-) ... [ ok ]>>> Unpacking source... >>> Unpacking libart_lgpl-2.3.19.tar.bz2 to /var/tmp/portage/media-libs/libart_lgpl-2.3.19-r1/work ./configure --prefix=/usr --host=arm-softfloat-linux-uclibc --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --build=i486-pc-linux-gnu checking for arm-softfloat-linux-uclibc-gcc... arm-softfloat-linux-uclibc-gcc checking whether arm-softfloat-linux-uclibc-gcc accepts -g... yes checking for arm-softfloat-linux-uclibc-gcc option to accept ISO C89... none needed checking build system type... i486-pc-linux-gnu checking host system type... arm-softfloat-linux-uclibc checking for arm-softfloat-linux-uclibc-g++... arm-softfloat-linux-uclibc-g++ checking whether we are using the GNU C++ compiler... yes checking for gfortran... gfortran configure: WARNING: In the future, Autoconf will not detect cross-tools whose name does not start with the host triplet. If you think this configuration is useful to you, please write to autoconf@gnu.org. configure: creating ./config.status config.status: creating libart-features.h config.status: creating Makefile config.status: creating libart-2.0.pc config.status: creating libart-2.0-uninstalled.pc config.status: creating libart-zip config.status: creating libart-config config.status: creating config.h config.status: executing depfiles commands arm-softfloat-linux-uclibc-gcc -DHAVE_CONFIG_H -I. -I. -I. -DLIBART_COMPILATION -Os -pipe -Wall -Wmissing-prototypes -MT gen_art_config.o -MD -MP -MF .deps/gen_art_config.Tpo -c -o gen_art_config.o gen_art_config.c mv -f .deps/gen_art_config.Tpo .deps/gen_art_config.Po /bin/sh ./libtool --tag=CC --mode=link arm-softfloat-linux-uclibc-gcc -Os -pipe -Wall -Wmissing-prototypes -o gen_art_config gen_art_config.o mkdir .libs arm-softfloat-linux-uclibc-gcc -Os -pipe -Wall -Wmissing-prototypes -o gen_art_config gen_art_config.o ./gen_art_config > art_config.h /bin/sh: ./gen_art_config: cannot execute binary file make: *** [art_config.h] Error 126 !!! ERROR: media-libs/libart_lgpl-2.3.19-r1 failed. Call stack: ebuild.sh, line 1621: Called dyn_compile ebuild.sh, line 973: Called qa_call 'src_compile' ebuild.sh, line 44: Called src_compile ebuild.sh, line 1311: Called gnome2_src_compile gnome2.eclass, line 71: Called die !!! compile failure !!! If you need support, post the topmost build error, and the call stack if relevant. !!! A complete build log is located at '/var/tmp/portage/media-libs/libart_lgpl-2.3.19-r1/temp/build.log'. file /var/tmp/portage/media-libs/libart_lgpl-2.3.19-r1/work/libart_lgpl-2.3.19/gen_art_config /var/tmp/portage/media-libs/libart_lgpl-2.3.19-r1/work/libart_lgpl-2.3.19/gen_art_config: ELF 32-bit LSB executable, ARM, version 1, dynamically linked (uses shared libs), not stripped
Do you have libart_lgpl installed on the host system? It's entirely possible that it cannot be cross compiled sanely, but we'll start with the above.
I looked in the make file; it tries to compile a small code that allows detection of the types on the target. Of course, the compilation of that file succedes, but that binary can't be ran. libart_lgpl should instead use inttypes.h to detect those types.
You should probably open a bug upstream, then, and post the URL here, so we can track it? RESOLVED FIXED doesn't seem to be the correct resolution for this...
I agree this bug can stay open until the real fix is available. It's not like we are greedy on closing bug rank :)
Created attachment 128318 [details, diff] patch for upstream cross building problem (non-bootstrapped source) This is the patch that should end up in upstream since it touches only the .am file from which the Makefile.in file is generated. Of course, it could be cleaner and the art_config.h file could be avoided entirely, but it seems that google returns results when looking for 'include art_config.h'; Thus the patch. I submitted it upstream: http://bugzilla.gnome.org/show_bug.cgi?id=467416
Created attachment 128320 [details, diff] patch for the bootstrapped source Same as before, but it extends the changes over Makefile.in, too (which is a by product of Makefile.am) to allow correct cross building on gentoo
Comment on attachment 128320 [details, diff] patch for the bootstrapped source I cross compile succesfully the package with this patch applied
I've committed an alternative. Can you try it out? It should have the same effect as your patch.
(In reply to comment #8) > I've committed an alternative. Can you try it out? It should have the same > effect as your patch. > It can't have the same effect as long as you did not define art_u* based on stdint.h definitions. The removed definitions are a side benefit of the patch, but not the main target of the patch.
<sigh> I can't believe I missed that. I must have been fooled by the endings on the types. I committed another try. Can you look?
(In reply to comment #10) > <sigh> I can't believe I missed that. I must have been fooled by the endings > on the types. > > I committed another try. Can you look? That is basically a clean up version of the initial patch I sent. It should be ok (the package xmerged). I haven't thoroughly checked the Makefile, but I guess xmerge would have barfed if something was wrong :-) .
It's slightly different; I got rid of the generation entirely, rather than copying over like you did. Thanks for testing.
