Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
Ebuild fails: x86_64-pc-linux-gnu-gcc -shared .libs/lirc_client.o -m -Wl,-soname -Wl,liblirc_client.so.0 -o .libs/liblirc_client.so.0.1.0 /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: unrecognised emulation mode: -Wl,-soname Supported emulations: elf_x86_64 elf_i386 i386linux collect2: ld returned 1 exit status emerge --info attached
Created an attachment (id=105434) [details] emerge --info
After tests from Sir-Satan, jakub, welp and whitehawk on amd64/x86 hardened/no-hardened I'm almost sure this problem occurs only on amd64/hardened.
Can you please poste a longer part of context, not only the last line before the error. Ideally attach a log of the complete emerge.
Created an attachment (id=106982) [details] Complete ebuild log, showing error
lirc also fails on my amd64-hardened system - exact same error as above. i tried disabled each optimization one by one but always received the same error. i was preparing my system for mythtv. didn't have lirc previously. i even tried disabling the only set lirc use flag "X". below is some system info: ________________________________________________ Linux caves 2.6.16-hardened-r11 #4 Mon Jan 29 15:37:38 CST 2007 x86_64 AMD Athlon(tm) 64 Processor 3200+ AuthenticAMD GNU/Linux ________________________________________________ USE="-X" emerge -Datv --oneshot lirc These are the packages that would be merged, in reverse order: Calculating dependencies... done! [ebuild N ] app-misc/lirc-0.8.0-r8 USE="-X -debug -doc -hardware-carrier -transmitter" LIRC_DEVICES="-act200l -act220l -adaptec -all -alsa_usb -animax -atilibusb -atiusb -audio -audio_alsa -avermedia -avermedia98 -avermedia_vdomate -bestbuy -bestbuy2 -breakoutbox -bte -bw6130 -caraca -chronos -cmdir -com1 -com2 -com3 -com4 -cph06x -creative -creative_infracd -devinput -digimatrix -dsp -dvico -ea65 -exaudio -flyvideo -gvbctv5pci -hauppauge -hauppauge_dvb -hercules_smarttv_stereo -igorplugusb -imon -imon_pad -imon_pad2keys -imon_rsc -inputlirc -irdeo -irdeo_remote -irman -irreal -it87 -knc_one -kworld -leadtek_0007 -leadtek_0010 -leadtek_pvr2000 -livedrive_midi -livedrive_seq -logitech -lpt1 -lpt2 -mceusb -mceusb2 -mediafocusI -mouseremote -mouseremote_ps2 -mp3anywhere -nslu2 -packard_bell -parallel -pcmak -pcmak_usb -pctv -pixelview_bt878 -pixelview_pak -pixelview_pro -provideo -realmagic -remote_wonder_plus -remotemaster -sa1100 -sasem -serial -serial_igor_cesko -silitek -sir -slinke -streamzap -tekram -tekram_bt829 -tira -tvbox -udp -uirt2 -uirt2_raw -usbirboy -userspace -xboxusb" 0 kB ________________________________________________ lirc_client.c: In function 'lirc_readconfig_only_internal': lirc_client.c:1160: warning: comparison is always false due to limited range of data type lirc_client.c:1178: warning: comparison is always false due to limited range of data type x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -MT lirc_client.lo -MD -MP -MF .deps/lirc_client.Tpo -c lirc_client.c -o lirc_client.o >/dev/null 2>&1 x86_64-pc-linux-gnu-gcc -m elf_x86_64 -o irw irw.o mv -f .deps/lirc_client.Tpo .deps/lirc_client.Plo /bin/sh ../libtool --tag=CC --mode=link x86_64-pc-linux-gnu-gcc -version-info 1:0:1 -m elf_x86_64 -o liblirc_client.la -rpath /usr/lib64 lirc_client.lo x86_64-pc-linux-gnu-gcc -m elf_x86_64 -o mode2 mode2.o x86_64-pc-linux-gnu-gcc -shared .libs/lirc_client.o -m -Wl,-soname -Wl,liblirc_client.so.0 -o .libs/liblirc_client.so.0.1.0 /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: unrecognised emulation mode: -Wl,-soname Supported emulations: elf_x86_64 elf_i386 i386linux collect2: ld returned 1 exit status make[2]: *** [liblirc_client.la] Error 1 make[2]: *** Waiting for unfinished jobs.... x86_64-pc-linux-gnu-gcc -m elf_x86_64 -o xmode2 xmode2.o -L/usr/lib64 /usr/lib64/libSM.so /usr/lib64/libICE.so /usr/lib64/libX11.so /usr/lib64/libXau.so /usr/lib64/libXdmcp.so -ldl make[2]: Leaving directory `/var/tmp/portage/lirc-0.8.0-r8/work/lirc-0.8.0/tools' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/lirc-0.8.0-r8/work/lirc-0.8.0' make: *** [all] Error 2 !!! ERROR: app-misc/lirc-0.8.0-r8 failed. Call stack: ebuild.sh, line 1546: Called dyn_compile ebuild.sh, line 937: Called src_compile ebuild.sh, line 1255: Called linux-mod_src_compile linux-mod.eclass, line 510: Called die !!! Unable to make all. ________________________________________________
Created an attachment (id=108553) [details] emerge --info
Created an attachment (id=108554) [details] lirc failed ebuild
in addition to lirc-0.8.0-r8, i also tried to emerge each of the ~amd64 higher version lirc-0.8.1 and the stable lower version lirc-0.8.0-r5, but both failed with the same error, "unrecognised emulation mode."
I have tried with all versions up to and including 0.8.2_pre2. Ebuild fails with the following: /bin/sh ../libtool --tag=CC --mode=link x86_64-pc-linux-gnu-gcc -march=athlon64 -mtune=athlon64 -pipe -O3 -fweb -frename-registers -fforce-addr -ftracer -m elf_x86_64 -o irw irw.o x86_64-pc-linux-gnu-gcc -shared .libs/lirc_client.o -march=athlon64 -mtune=athlon64 -m -Wl,-soname -Wl,liblirc_client.so.0 -o .libs/liblirc_client.so.0.2.0 /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: unrecognised emulation mode: -Wl,-soname Supported emulations: elf_x86_64 elf_i386 i386linux collect2: ld returned 1 exit status make[2]: *** [liblirc_client.la] Error 1 The problem appears to be the stray "-m" on the libtool commandline It must be an ebuild problem. If you do a manual make in /var/portage/app-misc/lirc-0.8.2_pre2/work/lirc-0.8.2pre2, it succeeds.
I have to retract my previous comment. It's not an ebuild bug, it's a libtool bug. I can reproduce it on the command line like so: # /bin/sh ../libtool --tag=CC --mode=link x86_64-pc-linux-gnu-gcc -march=athlon64 -mtune=athlon64 -pipe -O3 -fweb -frename-registers -fforce-addr -ftracer -version-info 2:0:2 -m elf_x86_64 -o liblirc_client.la -rpath /usr/lib64 lirc_client.lo rm -fr .libs/liblirc_client.a .libs/liblirc_client.la .libs/liblirc_client.lai .libs/liblirc_client.so .libs/liblirc_client.so.0 .libs/liblirc_client.so.0.2.0 x86_64-pc-linux-gnu-gcc -shared .libs/lirc_client.o -march=athlon64 -mtune=athlon64 -m -Wl,-soname -Wl,liblirc_client.so.0 -o .libs/liblirc_client.so.0.2.0 /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: unrecognised emulation mode: -Wl,-soname Supported emulations: elf_x86_64 elf_i386 i386linux collect2: ld returned 1 exit status Alternately, if I delete the space between the "-m" and "elf_x86_64", I get: # /bin/sh ../libtool --tag=CC --mode=link x86_64-pc-linux-gnu-gcc -march=athlon64 -mtune=athlon64 -pipe -O3 -fweb -frename-registers -fforce-addr -ftracer -version-info 2:0:2 -melf_x86_64 -o liblirc_client.la -rpath /usr/lib64 lirc_client.lo x86_64-pc-linux-gnu-gcc -shared .libs/lirc_client.o -march=athlon64 -mtune=athlon64 -melf_x86_64 -Wl,-soname -Wl,liblirc_client.so.0 -o .libs/liblirc_client.so.0.2.0 (cd .libs && rm -f liblirc_client.so.0 && ln -s liblirc_client.so.0.2.0 liblirc_client.so.0) (cd .libs && rm -f liblirc_client.so && ln -s liblirc_client.so.0.2.0 liblirc_client.so) x86_64-pc-linux-gnu-ar cru .libs/liblirc_client.a lirc_client.o x86_64-pc-linux-gnu-ranlib .libs/liblirc_client.a creating liblirc_client.la (cd .libs && rm -f liblirc_client.la && ln -s ../liblirc_client.la liblirc_client.la) It looks to me like this is actually a problem with how libtool handles the -m switch. I have libtool 1.5.23b installed. How do I fix that - I haven't been able to find where the flag gets set!
(In reply to comment #10) > How do I fix that - I haven't been able to find where the flag gets set! Well, I found it - at least a workaround. /usr/portage/profiles/hardened/make.defaults sets LDFLAGS_amd64="-m elf_x86_64" Change that to LDFLAGS_amd64="-melf_x86_64" And the package emerges! One of a number of things seem to be going on (maybe more than one): (1) libtool can't handle the argument -m elf_x86_64 correctly. (2) It may not be sensible to ask it to accept an ld argument that gcc does not accept - the form perhaps ought to be -Wl,-m -Wl,elf_x86_64 ? (3) That LDFLAGS_amd64 definition in /usr/portage/profiles/hardened/amd64/make.defaults is obsolete/dangerous/nonsensical and should be changed or shouldn't be there I'm not sure which is correct, and therefore what the correct fix is?
Has the cause of this bug been determined yet? > Well, I found it - at least a workaround. > /usr/portage/profiles/hardened/make.defaults sets > LDFLAGS_amd64="-m elf_x86_64" > > Change that to > LDFLAGS_amd64="-melf_x86_64" I do not have the above in my /usr/portage/profiles/hardened/make.defaults. Instead I had to modify /usr/portage/profiles/hardened/amd64/make.defaults > > And the package emerges! > > One of a number of things seem to be going on (maybe more than one): > (1) libtool can't handle the argument -m elf_x86_64 correctly. > (2) It may not be sensible to ask it to accept an ld argument that gcc does not > accept - the form perhaps ought to be -Wl,-m -Wl,elf_x86_64 ? > (3) That LDFLAGS_amd64 definition in > /usr/portage/profiles/hardened/amd64/make.defaults is > obsolete/dangerous/nonsensical and should be changed or shouldn't be there > > I'm not sure which is correct, and therefore what the correct fix is? >
*** Bug 216145 has been marked as a duplicate of this bug. ***
Does lirc-0.8.3 still have this bug?
(In reply to comment #14) > Does lirc-0.8.3 still have this bug? > lirc-0.8.3-r2 does.
Anyone using a hardened/arch profile is urged to update to a current profile. Please use eselect profile list to select a hardened/linux/arch/10.0 profile.
After upgrading to the 10.0 profile worked for me on AMD64/multilib :)
Seems to me its a problem of the pkg build system doing something funny. LDFLAGS_amd64="-m elf_x86_64" is valid. Ref: http://devmanual.gentoo.org/archs/amd64/index.html I don't think its really necessary to have in the profile anymore, but I don't think its wrong either. As Jory stated, hardened/${arch} profiles are going to be deprecated very shortly, so I'm not going to remove it and risk a problem. Re-assigning to pkg owner to decide what they want to do about the pkg with repsect to its handling of LDFLAGS_amd64.
It should have use -Wl,foo When passing linking flags tru gcc, -Wl should be just. And it is removed in the newer profiles so it not longer a problem and i will close this bug.
