failing line: x86_64-pc-linux-gnu-as -f elf64 -I./ -I"/var/tmp/portage/media-libs/libvpx-0.9.5/work/libvpx-v0.9.5"/ -o vp8/common/x86/idctllm_mmx.asm.o vp8/common/x86/idctllm_mmx.asm which results in this: Assembler messages: Error: can't open elf64 for reading: No such file or directory That additional ASFLAG is added in build/make/configure.sh, since it detects my target as a linux one. Additionally, user CFLAGS are overwritten, especially -O* and -m* are overwritten, which does neither allow the optimization level nor crosscompilation. There are probably more issues, which will cause issues with a normal crosscompile run with this custom configure script. emerge --info: Portage 2.2.0_alpha2-r1 (hardened/linux/amd64/10.0, gcc-4.4.5, glibc-2.12.1-r3, 2.6.36-gentoo x86_64) ================================================================= System uname: Linux-2.6.36-gentoo-x86_64-Intel-R-_Core-TM-2_Quad_CPU_Q6600_@_2.40GHz-with-gentoo-2.0.1 Timestamp of tree: Thu Nov 11 07:41:21 CET 2010 ccache version 2.4 [disabled] app-shells/bash: 4.1_p9 dev-java/java-config: 2.1.11-r2 dev-lang/python: 2.6.6-r1, 2.7 dev-util/ccache: 2.4-r8 dev-util/cmake: 2.8.1-r2 sys-apps/baselayout: 2.0.1-r1 sys-apps/openrc: 0.6.3 sys-apps/sandbox: 2.3-r1::Meins sys-devel/autoconf: 2.13, 2.68 sys-devel/automake: 1.4_p6-r1, 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 4.4.5, 4.5.1 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.4 sys-devel/make: 3.82 virtual/os-headers: 2.6.35 (sys-kernel/linux-headers) Repositories: gentoo java-overlay enlightenment hardened-dev science sunrise multilib Meins ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=native -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/config /var/lib/hsqldb" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-march=native -O2 -pipe" DISTDIR="/home/thomas/daten/distfiles" EMERGE_DEFAULT_OPTS="--keep-going --backtrack=6" FEATURES="assume-digests binpkg-logs collision-protect distlocks fixlafiles fixpackages metadata-transfer news parallel-fetch preserve-libs protect-owned sandbox sfperms sign strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox" GENTOO_MIRRORS="http://ftp.spline.inf.fu-berlin.de/mirrors/gentoo/ ftp://ftp.uni-erlangen.de/pub/mirrors/gentoo ftp://ftp.snt.utwente.nl/pub/os/linux/gentoo" INSTALL_MASK="/usr/share/gtk-doc" LANG="de_DE.UTF-8@euro" LC_ALL="de_DE.UTF-8@euro" LDFLAGS="-Wl,--as-needed -Wl,--hash-style=gnu" LINGUAS="de" MAKEOPTS="-j5 --load-average=8" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage/layman/java-overlay /usr/local/portage/layman/enlightenment /usr/local/portage/layman/hardened-development /usr/local/portage/layman/science /usr/local/portage/layman/sunrise /usr/local/portage/layman/multilib /usr/local/portage" SYNC="cvs://tommy@cvs.gentoo.org:/var/cvsroot" USE="3dnow X alsa amd64 berkdb cli cracklib crypt cups custom-cflags custom-cxxflags custom-optimization cxx dri gpm hardened java5 java6 justify mmx modules mudflap multilib multilib_abi_amd64 multilib_abi_x86 ncurses nls nptl nptlonly nsplugin ogg opengl openmp pam pic pppd readline scanner session sse sse2 ssl sysfs tcpd unicode urandom vorbis xorg zlib" ALSA_CARDS="hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de" MULTILIB_ABIS="amd64 x86" PHP_TARGETS="php5-2" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="nvidia" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, FFLAGS, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
(In reply to comment #0) > failing line: > > x86_64-pc-linux-gnu-as -f elf64 -I./ > -I"/var/tmp/portage/media-libs/libvpx-0.9.5/work/libvpx-v0.9.5"/ -o > vp8/common/x86/idctllm_mmx.asm.o vp8/common/x86/idctllm_mmx.asm > > which results in this: > > Assembler messages: > Error: can't open elf64 for reading: No such file or directory > > That additional ASFLAG is added in build/make/configure.sh, since it detects my > target as a linux one. > > Additionally, user CFLAGS are overwritten, especially -O* and -m* are > overwritten, which does neither allow the optimization level nor > crosscompilation. There are probably more issues, which will cause issues with > a normal crosscompile run with this custom configure script. a quick fix for this cross compile is to add --as=yasm to the ./configure command in the ebuild (the asflags that are added byu the config.sh script are for yasm) with tihs the autodetect is disabled and yasm is hardcocded this fix also works with multilib-portage
(In reply to comment #1) > a quick fix for this cross compile is to add --as=yasm to the ./configure > command in the ebuild (the asflags that are added byu the config.sh script are > for yasm) > with tihs the autodetect is disabled and yasm is hardcocded > > this fix also works with multilib-portage > I am using multilib portage and I have this issue, using above mentioned fix solves the problem, fix confirmed.
(In reply to comment #2) > (In reply to comment #1) > > > a quick fix for this cross compile is to add --as=yasm to the ./configure > > command in the ebuild (the asflags that are added byu the config.sh script are > > for yasm) > > with tihs the autodetect is disabled and yasm is hardcocded > > > > this fix also works with multilib-portage > > > > I am using multilib portage and I have this issue, using above mentioned fix > solves the problem, fix confirmed. Just to add that this bug is still occurring with libvpx-0.9.5-r1
This build prevents building of the chromium 10.0.648.82 an later since it requires 0.9.5 or above
If there is no response or action within the next 2 weeks, i will touch libvpx and do the needed changes.
Adding --as=yasm is also needed for 0.9.6 and allows it to build.
Created attachment 270795 [details] libvpx-0.9.5.ebuild with --as=yasm fix added. Also confirming issue on multilib-portage, and confirming fix. I went ahead and attached my ebuild for 0.9.5 incase it helps anyone.
28 May 2011; Thomas Sachau (Tommy[D]) <tommy@gentoo.org> libvpx-0.9.6.ebuild: Adding workaround for bug 345161, forces yasm as as interpreter and adjusts the target platform for cross-compilation why is this bug still open ?
(In reply to comment #8) > why is this bug still open ? I don't know, the current version of media-libs/libvpx-0.9.6 compiles perfectly fine on portage-multilib for me.
In my eyes, my commit contains a workaround and i wanted to leave this bug open, so that the maintainer can either confirm it as a fix or can do something else to fix the issue and gets reminded by this open bug.
(In reply to comment #10) > In my eyes, my commit contains a workaround and i wanted to leave this bug > open, so that the maintainer can either confirm it as a fix or can do something > else to fix the issue and gets reminded by this open bug. hmm, yes it needs a better fix imho does a patch like this helps without setting anything like --as or --target, just by exporting CC ? diff --git a/build/make/configure.sh b/build/make/configure.sh index 23cf443..a046ed1 100755 --- a/build/make/configure.sh +++ b/build/make/configure.sh @@ -523,7 +523,7 @@ setup_gnu_toolchain() { process_common_toolchain() { if [ -z "$toolchain" ]; then - gcctarget="$(gcc -dumpmachine 2> /dev/null)" + gcctarget="$(${CC:-${CROSS}gcc} -dumpmachine 2> /dev/null)" # detect tgt_isa case "$gcctarget" in
(In reply to comment #11) > (In reply to comment #10) > > In my eyes, my commit contains a workaround and i wanted to leave this bug > > open, so that the maintainer can either confirm it as a fix or can do something > > else to fix the issue and gets reminded by this open bug. > > hmm, yes it needs a better fix imho > > does a patch like this helps without setting anything like --as or --target, > just by exporting CC ? > > diff --git a/build/make/configure.sh b/build/make/configure.sh > index 23cf443..a046ed1 100755 > --- a/build/make/configure.sh > +++ b/build/make/configure.sh > @@ -523,7 +523,7 @@ setup_gnu_toolchain() { > > process_common_toolchain() { > if [ -z "$toolchain" ]; then > - gcctarget="$(gcc -dumpmachine 2> /dev/null)" > + gcctarget="$(${CC:-${CROSS}gcc} -dumpmachine 2> /dev/null)" > > # detect tgt_isa > case "$gcctarget" in workaround dropped in -9999, reopen once you've answered the question :)
(In reply to comment #12) > workaround dropped in -9999, reopen once you've answered the question :) to be read as : workaround has never been in -9999, and is dropped in 1.0.0 :)
a short ping would have been enough, since i simply missed your comment ;-) Anyway, this does not fix the problem, the error message is still exactly the same. So please revert this change for libvpx-1.0.0
(In reply to comment #14) > a short ping would have been enough, since i simply missed your comment ;-) > > Anyway, this does not fix the problem, the error message is still exactly > the same. So please revert this change for libvpx-1.0.0 we'll have to investigate a proper solution, i'm not fond of keeping workarounds forever :) why is your AS set to x86_64-pc-linux-gnu-as ? do you export this variable ?
Line 235 in bin/auto-multilib.sh does define: export AS="$(tc-getPROG AS as)" You can see the definition of environment vars around that line here: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=blob;f=bin/auto-multilib.sh;hb=refs/heads/multilib
(In reply to comment #16) > Line 235 in bin/auto-multilib.sh does define: > export AS="$(tc-getPROG AS as)" > > You can see the definition of environment vars around that line here: > http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=blob;f=bin/auto- > multilib.sh;hb=refs/heads/multilib does 'unset AS' lets the build system autodetection work and works fine for you ?
(In reply to comment #16) > Line 235 in bin/auto-multilib.sh does define: > export AS="$(tc-getPROG AS as)" > > You can see the definition of environment vars around that line here: > http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=blob;f=bin/auto- > multilib.sh;hb=refs/heads/multilib thinking about it, care to explain why you need to do this ? ebuilds requiring AS to be set for cross-compiling should tc-export it, if they dont its a bug.
If you look at the function, then you can see, that it does first define CHOST for the current arch and then exports those vars (AS, CC, CXX, FC) before it actually does redefine CHOST to match the target ABI. Otherwise, those functions (e.g. called in the ebuild) could be confused by CHOST and select a different cross-compiler then it actually should use, e.g. some i686-* compiler instead of x86_64-* ones. The comments do mention bug 202811, which shows some issues without this order of definition. Unsetting AS e.g. at the beginning of src_configure does also work around this compile failure.
(In reply to comment #19) > If you look at the function, then you can see, that it does first define > CHOST for the current arch and then exports those vars (AS, CC, CXX, FC) > before it actually does redefine CHOST to match the target ABI. > Otherwise, those functions (e.g. called in the ebuild) could be confused by > CHOST and select a different cross-compiler then it actually should use, > e.g. some i686-* compiler instead of x86_64-* ones. > The comments do mention bug 202811, which shows some issues without this > order of definition. > > Unsetting AS e.g. at the beginning of src_configure does also work around > this compile failure. good, then please add this (unconditionally) in 1.0.0 and 9999, with a comment that one shall let the build system decide which AS to use (it honours $AS but then feeds it with yasm flags without checking...); i didnt like the previous workaround as it didnt take into account, e.g, x86-* and amd64-* hosts (prefix, bsds, etc.) and was doing some weird 'if then else' special casing
(In reply to comment #20) > good, then please add this (unconditionally) in 1.0.0 and 9999, with a > comment that one shall let the build system decide which AS to use (it > honours $AS but then feeds it with yasm flags without checking...); > > i didnt like the previous workaround as it didnt take into account, e.g, > x86-* and amd64-* hosts (prefix, bsds, etc.) and was doing some weird 'if > then else' special casing Done. I leave the closing of this bug to you, if you are ok with this workaround.
well now it's just broken in a different way for some targets :( i think the only sane thing to do here is to not use ASFLAGS when invoking yasm
i've reduced the issue to amd64/x86 since those are the only platforms that use nasm/yasm. my use case that is failing is arm anyways ;). http://sources.gentoo.org/media-libs/libvpx/libvpx-1.1.0.ebuild?r1=1.13&r2=1.14 http://sources.gentoo.org/media-libs/libvpx/libvpx-9999.ebuild?r1=1.27&r2=1.28
(In reply to comment #23) > i've reduced the issue to amd64/x86 since those are the only platforms that > use nasm/yasm. my use case that is failing is arm anyways ;). > > http://sources.gentoo.org/media-libs/libvpx/libvpx-1.1.0.ebuild?r1=1.13&r2=1. > 14 > http://sources.gentoo.org/media-libs/libvpx/libvpx-9999.ebuild?r1=1.27&r2=1. > 28 better improving upstream autodetection instead of adding hacks...
(In reply to comment #24) (1) this bug is still open (2) the ebuild is broken *today* and *already* has hacks (3) i've already gotten multiple fixes merged upstream (4) you can just as easily fix this upstream yourself (seeing as you're also the maintainer here)
(In reply to comment #25) > (In reply to comment #24) > > (1) this bug is still open and shouldnt have been, i only forgot to close it > (2) the ebuild is broken *today* and *already* has hacks the 'hacks' that were introduced due to this bug were, on purpose, minimal. as of broken, its hard to say with the info provided in comment #22 > (3) i've already gotten multiple fixes merged upstream good :) so please do submit them real fixes, hardcoding a list of arches is not one of these, sadly. > (4) you can just as easily fix this upstream yourself (seeing as you're also > the maintainer here) yes, when i consider there is something to fix there...
(In reply to comment #26) it failed the minimal test as soon as it broke other targets
(In reply to comment #27) > (In reply to comment #26) > > it failed the minimal test as soon as it broke other targets bug # ? I hope you dont expect me to maintain an undocumented hack I dont agree with and dont understand...
a more acceptable solution could be to define a YASM_ARCH variable, use it to add yasm to DEPEND and unset AS (or set it to yasm) in src_*
(In reply to comment #28) it's just as "undocumented" as the old hack. my change was *fixing* the old hack, not adding a new one. just *think* about it logically ... it's really quite simple. you're not setting up $AS anywhere. the build system relies on $AS. only x86/amd64 use yasm/nasm. now, logically, where is it going to fail ? everywhere else. (In reply to comment #29) that doesn't work as the yasm dependency depends purely on the arch (which is a USE setting), and you can't execute `use` in global scope which means you can't initialize *DEPEND with it. even if you could, you'd simply be taking the code i already wrote and hoisting it up a layer.
(In reply to comment #30) > (In reply to comment #28) > > it's just as "undocumented" as the old hack. my change was *fixing* the old > hack, not adding a new one. > > just *think* about it logically ... it's really quite simple. you're not > setting up $AS anywhere. the build system relies on $AS. only x86/amd64 > use yasm/nasm. now, logically, where is it going to fail ? everywhere else. you might want to read configure.sh before making such claims. there's autodetection, it does not rely on AS, rather the contrary where yasm is used. After talking with steev, it seems it fails on arm because they set CROSS if it is not set, and to a wrong value for us. setting CROSS=${CHOST}- in the env will probably do it. had you discussed this before shooting and actually provided a real error would have helped understanding... > (In reply to comment #29) > > that doesn't work as the yasm dependency depends purely on the arch (which > is a USE setting), and you can't execute `use` in global scope which means > you can't initialize *DEPEND with it. even if you could, you'd simply be > taking the code i already wrote and hoisting it up a layer. you misunderstood it seems...
(In reply to comment #31) you forgot how the build system works. you cannot rely on CHOST-as alone, you *must* respect env $AS.
(In reply to comment #32) > (In reply to comment #31) > > you forgot how the build system works. you cannot rely on CHOST-as alone, > you *must* respect env $AS. which is incorrect in this precise case and is exactly why this bug was opened in the first place...
+ 25 Jun 2013; Alexis Ballier <aballier@gentoo.org> libvpx-9999.ebuild: + set AS to yasm based on CHOST which seems to be the sanest to do, bug #345161 +
