Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

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 an attachment (id=128318) [details]
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 an attachment (id=128320) [details]
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

(From update of attachment 128320 [details])
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.