| Summary: | LD_FLAGS_arch sets a buggy -m argument on various profiles | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Francisco Blas Izquierdo Riera <klondike> |
| Component: | Eclasses | Assignee: | Gentoo Linux bug wranglers <bug-wranglers> |
| Status: | RESOLVED INVALID | ||
| Severity: | major | CC: | gengor |
| Priority: | High | ||
| Version: | 2008.0 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 160134 | ||
|
Description
Francisco Blas Izquierdo Riera (RETIRED)
2009-09-13 23:59:43 UTC
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. |