LD_FLAGS_arch sets a buggy -m argument adding a space betwen the -m and the emulation mode in various profiles which makes some ebuilds to fail. Reproducible: Always Steps to Reproduce: 1. Build a package (ie in which depends on the LD_FLAGS in any of the affected profiles 2. The build fails with an ld error Actual Results: The ebuild crashes with an LD error Expected Results: The ebuild builds This fails mainly on some old profiles like the old hardened/amd64 ebuild. But seems to be solved on newer profiles. A fast lookup on the profiles directory outputs the following: kdk-Desktop ~ # grep -r LD /usr/portage/profiles/ | grep -Fe "-m "| cut -d: -f1 /usr/portage/profiles/default-linux/amd64/make.defaults /usr/portage/profiles/default-linux/sparc/sparc32/make.defaults /usr/portage/profiles/default-linux/sparc/sparc64/make.defaults /usr/portage/profiles/default-linux/sparc/sparc64/make.defaults /usr/portage/profiles/hardened/amd64/make.defaults /usr/portage/profiles/hardened/amd64/multilib/make.defaults /usr/portage/profiles/hardened/amd64/multilib/make.defaults /usr/portage/profiles/arch/amd64-fbsd/make.defaults /usr/portage/profiles/arch/amd64/make.defaults /usr/portage/profiles/arch/powerpc/ppc64/make.defaults /usr/portage/profiles/arch/powerpc/ppc64/make.defaults /usr/portage/profiles/arch/sparc/make.defaults
Can you provide any other failing ebuilds besides app-misc/lirc in bug 160134? LDFLAGS_amd64="-m elf_x86_64" is valid (though only in use on hardened/amd64 and probably not needed anymore either). Ref: http://devmanual.gentoo.org/archs/amd64/index.html I really think it is app-misc/lirc build system doing something funny. Closing as INVALID, re-open if you have evidence the problem is more wide-spread than app-misc/lirc.
The thing is that according to the ld info page the -m option must not be followed by an space, that any eclass fixes it and solves the problem for almost all the packages doesn't mean that the bugs is not there. Just a simple paste from the ld info page to show my point: `-mEMULATION' Emulate the EMULATION linker. You can list the available emulations with the `--verbose' or `-V' options. If the `-m' option is not used, the emulation is taken from the `LDEMULATION' environment variable, if that is defined. Otherwise, the default emulation depends upon how the linker was configured. And here the lines on the affected profiles: /usr/portage/profiles/default-linux/amd64/make.defaults:LDFLAGS_x86="-m elf_i386 -L/emul/linux/x86/lib -L/emul/linux/x86/usr/lib" /usr/portage/profiles/default-linux/sparc/sparc32/make.defaults:LDFLAGS_sparc32="-m elf32_sparc" /usr/portage/profiles/default-linux/sparc/sparc64/make.defaults:LDFLAGS_sparc64="-m elf64_sparc" /usr/portage/profiles/default-linux/sparc/sparc64/make.defaults:LDFLAGS_sparc32="-m elf32_sparc" /usr/portage/profiles/hardened/amd64/make.defaults:LDFLAGS_amd64="-m elf_x86_64" /usr/portage/profiles/hardened/amd64/multilib/make.defaults:#LDFLAGS_amd64="-m elf_x86_64" /usr/portage/profiles/hardened/amd64/multilib/make.defaults:LDFLAGS_x86="-m elf_i386 -L/emul/linux/x86/lib -L/emul/linux/x86/usr/lib" /usr/portage/profiles/arch/amd64-fbsd/make.defaults:LDFLAGS_x86_fbsd="-m elf_i386_fbsd" /usr/portage/profiles/arch/amd64/make.defaults:LDFLAGS_x86="-m elf_i386" /usr/portage/profiles/arch/powerpc/ppc64/make.defaults:LDFLAGS_ppc64="-m elf64ppc" /usr/portage/profiles/arch/powerpc/ppc64/make.defaults:LDFLAGS_ppc="-m elf32ppc" /usr/portage/profiles/arch/sparc/make.defaults:LDFLAGS_sparc64="-m elf64_sparc" The odd thing is that according to ld --help the space should be there :/ Anyway, after deleting the space I didn't found a problem with the other packages.
The space is ok/valid and used that way quite often. I think lirc build is just doing something funny, perhaps try running its compile step with ebuild --debug.
Well I have to give you the reason, the problem is in this strange call: /bin/sh ../libtool --tag=CC --mode=link x86_64-pc-linux-gnu-gcc -O2 -pipe -fweb -frename-registers -fomit-frame-pointer -march=core2 -version-info 2:1:2 -m elf_x86_64 -o liblirc_client.la -rpath /usr/lib64 lirc_client.lo x86_64-pc-linux-gnu-gcc -shared .libs/lirc_client.o -march=core2 -m -Wl,-soname -Wl,liblirc_client.so.0 -o .libs/liblirc_client.so.0.2.1 Though I can't see how it gets to there.
