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 attachment 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 attachment 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 attachment 108553 [details] emerge --info
Created attachment 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.
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/profiles/arch/amd64/make.defaults?r1=1.9&r2=1.10 LDFLAGS_amd64="-m elf_x86_64" was added on 2011/12/07 to make.defaults breaking lirc 0.9.0 and 0.8.7. Perphaps this bug should be re-opened? The build failure is the same as before: ld: unrecognised emulation mode: -Wl,-soname Supported emulations: elf_x86_64 elf_i386 i386linux
I am seeing this as well, I agree it should be re-opened and a bug should be filed with the portage/profile maintainers to notify them that it breaks specifically this package (but perhaps others that use libtool as well).
I encounter this issue too on amd64 system (desktop/gnome profile), I have to manually alter the emerge environment by prefixing LDFLAGS_amd64='-melf...' to make lirc to emerge successfully!
Please do not CC arches on your own
One question: Isn't this a problem with libtool/autoconf? After all, it's the libtool script that is partially removing the option incorrectly. The fact that the option was added to the profile only brought the bug to the surface. By the way, I can confirm this problem on my AMD64 system. My current profile is: default/linux/amd64/10.0/desktop My workaround was: LDFLAGS_amd64="" emerge -1av app-misc/lirc
*** Bug 218717 has been marked as a duplicate of this bug. ***
*** Bug 396537 has been marked as a duplicate of this bug. ***
*** Bug 396653 has been marked as a duplicate of this bug. ***
(In reply to comment #24) no, this is not a bug in libtool or any autotools. it is completely a problem with lirc. read bug 396537 comment 5.
Created attachment 310479 [details, diff] Patch to fix lirc-0.9.0.ebuild Incredible how long this bug has remained unresolved. Seriously, 5 years!?! Okay, here's the problem: The lirc build system attempts to configure kernel modules using autotools/libtool, this is problematic due to the fact that the kernel tree has differing ideas about certain things than autotools, in particular LDFLAGS, which in the kernel are "raw" as passed directly to ld, whereas userland packages typically pass LDFLAGS though gcc utilising the linker-flag prefix "-Wl". Solution: 1. Make configure happy by setting up ABI to build kernel modules in the same way as linux-mod.eclass, this allows the drivers to be configured sucessfully. 2. Do not use linux-mod.ecass to run econf, but do so directly by utilising EXTRA_ECONF (and econf src_compile) in place of ECONF_PARAMS, linux-mod.ecass automagically does the right thing. 3. Separate the userland/kernel build process, so "make all" from the top-level only builds userland (autotools style). 4. Use linux-mod.eclass src_compile stage to *only* build the kernel modules in the "drivers" subdir not the top-level srcdir. 5. Install the drivers after installing the userspace part from the top-level srcdir.
(In reply to comment #29) > Created attachment 310479 [details, diff] [details, diff] > Patch to fix lirc-0.9.0.ebuild > > Incredible how long this bug has remained unresolved. Seriously, 5 years!?! > > Okay, here's the problem: > > The lirc build system attempts to configure kernel modules using > autotools/libtool, this is problematic due to the fact that the kernel tree > has differing ideas about certain things than autotools, in particular > LDFLAGS, which in the kernel are "raw" as passed directly to ld, whereas > userland packages typically pass LDFLAGS though gcc utilising the > linker-flag prefix "-Wl". > > Solution: > > 1. Make configure happy by setting up ABI to build kernel modules in the > same way as linux-mod.eclass, this allows the drivers to be configured > sucessfully. > > 2. Do not use linux-mod.ecass to run econf, but do so directly by utilising > EXTRA_ECONF (and econf src_compile) in place of ECONF_PARAMS, > linux-mod.ecass automagically does the right thing. > > 3. Separate the userland/kernel build process, so "make all" from the > top-level only builds userland (autotools style). > > 4. Use linux-mod.eclass src_compile stage to *only* build the kernel modules > in the "drivers" subdir not the top-level srcdir. > > 5. Install the drivers after installing the userspace part from the > top-level srcdir. worked like a charm on my x86_64
*** Bug 417893 has been marked as a duplicate of this bug. ***
*** Bug 417645 has been marked as a duplicate of this bug. ***
Same problem here on ~amd64 profile desktop and MAKEOPTS="-j5" in make.conf. To run emerge with MAKEOPTS="-j1" work for me.
(In reply to comment #33) > Same problem here on ~amd64 profile desktop and MAKEOPTS="-j5" in make.conf. > To run emerge with MAKEOPTS="-j1" work for me. Sorry, I am on the wrong bug. -j1 doesn't work in that case.
I used the patch attached, and lirc builds now! Interesting: I have an other machine, it is ~amd64 and genlop shows: Tue Jun 14 21:54:42 2011 >>> app-misc/lirc-0.9.0 So it worked then! I tried to remerge it, but it failed... It works there with the patch too. I don't know what changed since, (everything :D ) I hope -r1 will be in the tree soon, I think the current state of the ebuild is not working.
The patch failed for me, likely due to the hard pathes: >>> Emerging (1 of 1) app-misc/lirc-0.9.0 from local * lirc-0.9.0.tar.bz2 RMD160 SHA1 SHA256 size ;-) ... [ ok ] * QA Notice: USE Flag 'lirc_devices_mceusb2' not in IUSE for app-misc/lirc-0.9.0 * QA Notice: USE Flag 'lirc_devices_mceusb' not in IUSE for app-misc/lirc-0.9.0 * If your LIRC device requires modules, you'll need MODULE_UNLOAD * support in your kernel. * Determining the location of the kernel source code * Found kernel source directory: * /usr/src/linux * Found kernel object directory: * /lib/modules/3.4.0/build * Found sources for kernel version: * 3.4.0 * * Compiling only the lirc-applications, but no drivers. * Enable drivers with LIRC_DEVICES if you need them. * * lirc-configure-opts: --with-driver=none * Setting default lirc-device to /dev/lirc0 >>> Unpacking source... >>> Unpacking lirc-0.9.0.tar.bz2 to /var/tmp/portage/app-misc/lirc-0.9.0/work * Applying lirc-0.8.4-portaudio_check.patch ... [ ok ] * Applying lirc-0.9.0.ebuild.diff ... * Failed Patch: lirc-0.9.0.ebuild.diff ! * ( /usr/local/portage/app-misc/lirc/files/lirc-0.9.0.ebuild.diff )
Created attachment 314769 [details] /var/tmp/portage/app-misc/lirc-0.9.0/temp/lirc-0.9.0.ebuild.diff.out
(In reply to comment #29) Your patch works for me too. Thanks!
(In reply to comment #36) ... > * Applying lirc-0.9.0.ebuild.diff ... > > * Failed Patch: lirc-0.9.0.ebuild.diff ! > * ( /usr/local/portage/app-misc/lirc/files/lirc-0.9.0.ebuild.diff ) It's a patch against the ebuild itself not for the package.
(In reply to comment #29) > Created attachment 310479 [details, diff] [details, diff] > Patch to fix lirc-0.9.0.ebuild > > Incredible how long this bug has remained unresolved. Seriously, 5 years!?! Far too long, thank you for solving this! Works for me on stable x86_64, too.
(In reply to comment #40) > (In reply to comment #29) > > Created attachment 310479 [details, diff] [details, diff] [details, diff] > > Patch to fix lirc-0.9.0.ebuild > > > > Incredible how long this bug has remained unresolved. Seriously, 5 years!?! > > Far too long, thank you for solving this! Works for me on stable x86_64, too. Kind of a me too, but for a diferent version. I used the 0.9.0 patch and manually applied it to 0.8.7 and it fixed the issue for me as well.
Unpatched versions of lirc have not worked for me since the beginning of this year (I think since 0.9.0 was introduced to the tree). Seven months now of updating kernels and before rebuilding lirc against the new kernels, I have to apply the patch from this bug report: https://bugs.gentoo.org/show_bug.cgi?id=396653 Can we PLEASE get this into portage?
+*lirc-0.9.0-r1 (17 Jul 2012) + + 17 Jul 2012; Ian Stakenvicius <axs@gentoo.org> +files/lircd-0.8.6-r1, + +lirc-0.9.0-r1.ebuild, +files/lircd.conf.3: + converted ebuild to EAPI4, made drivers build separately from tools to fix + bug 160134, fixed init script so that socket path exists (bug 414307), added + option so that init script can set 'lirc' as the kernel IR decoding protocol + on startup (bug 368489) + Please test.
*** Bug 419447 has been marked as a duplicate of this bug. ***
Compiles and works fine! Thank You.
