Summary: | app-misc/lirc-0.9.0 fails to emerge because of unrecognised emulation mode: -Wl,-soname | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Juergen Rose <rose> |
Component: | Current packages | Assignee: | Television related Applications in Gentoo's Portage <media-tv> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | aeriksson, da5id2001, dominique.c.michel, gentoo, justin.t.riley, maggu2810, michael, milton, patrick.rouzet, patrick, polidevk.polidevk, tpfaff, womble |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 403309 | ||
Attachments: |
/var/tmp/portage/app-misc/lirc-0.9.0/temp/build.log
patch for lirc 0.9.0 ebuild the build log my emerge --info patched ebuild with disabled get_abi_LDFLAGS |
Description
Juergen Rose
2012-01-01 08:05:27 UTC
Created attachment 297509 [details]
/var/tmp/portage/app-misc/lirc-0.9.0/temp/build.log
Created attachment 297795 [details, diff]
patch for lirc 0.9.0 ebuild
Same here, please consider the patch for the lirc ebuild.
With the patched ebuild emerging lirc worked for me,
thanks for the patch. The patched worked for me too. Patched worked for me too. Thank you, Thomas. Almost two weeks later I hit this issue again during 'emerge -uvDNe system'. Could someone add the patch to the standard portage tree? Third time since the patch was posted that I ran into this after a kernel upgrade. Can we please get this in portage ASAP. Just encountered this myself. Put the patched ebuild in my overlay: http://git.overlays.gentoo.org/gitweb/?p=user/jtriley.git Created attachment 301897 [details]
the build log
just encountered this in the stable o.8.7
Created attachment 301899 [details]
my emerge --info
+src_compile() { + econf ${ECONF_PARAMS} || "die configure failed" that should be in src_configure and looks very default why would that fix building lirc? (In reply to comment #11) > +src_compile() { > + econf ${ECONF_PARAMS} || "die configure failed" > > that should be in src_configure and looks very default > > why would that fix building lirc? I hit the same bug today. And just by chance I had an old logfile of a successfull emerge of lirc-0.8.7 around, and used it to to check for differences, although lirc-0.8.7 does not compile anymore for my setup. It seems that the current ebuild invokes make with an LDFLAGS arg as make ... 'LDFLAGS=-m elf_x86_64' all whereas the old logfile shows the line make ... LDFLAGS= all and indeed simply invoking make without the LDFLAGS arg works for me, and I think that is how the ebuild patch from Thomas works, too. The relevant rather long lines from my two log files are: lirc-0.9.0, current failed emerge: make -j3 -j1 HOSTCC=x86_64-pc-linux-gnu-gcc CROSS_COMPILE=x86_64-pc-linux-gnu- 'LDFLAGS=-m elf_x86_64' all ... /bin/sh ../libtool --tag=CC --mode=link x86_64-pc-linux-gnu-gcc -march=athlon64 -O2 -pipe -version-info 2:1:2 -m elf_x86_64 -o liblirc_client.la -rpath /usr/lib64 lirc_client.lo libtool: link: x86_64-pc-linux-gnu-gcc -shared -fPIC -DPIC .libs/lirc_client.o -march=athlon64 -O2 -m -Wl,-soname -Wl,liblirc_client.so.0 -o .libs/liblirc_client.so.0.2.1 /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../x86_64-pc-linux-gnu/bin/ld: unrecognised emulation mode: -Wl,-soname lirc-0.8.7-OLD-SETUP-WHICH-HAS-WORKED-ONCE-BUT-DOES-NOT-ANYMORE: make -j3 -j1 HOSTCC=x86_64-pc-linux-gnu-gcc CROSS_COMPILE=x86_64-pc-linux-gnu- LDFLAGS= all ... /bin/sh ../libtool --tag=CC --mode=link x86_64-pc-linux-gnu-gcc -march=athlon64 -O2 -pipe -version-info 2:1:2 -o liblirc_client.la -rpath /usr/lib64 lirc_client.lo libtool: link: x86_64-pc-linux-gnu-gcc -shared .libs/lirc_client.o -march=athlon64 -Wl,-soname -Wl,liblirc_client.so.0 -o .libs/liblirc_client.so.0.2.1 ... [success] or in short: OLD: make ... LDFLAGS= all NEW: make ... 'LDFLAGS=-m elf_x86_64' all OLD: /bin/sh ../libtool ... libtool: link: ... NEW: /bin/sh ../libtool ... -m elf_x86_64 ... libtool: link: ... -m -Wl,-soname ... # # the 'elf_x86_64' option is dropped by libtool, but the '-m' is not. # As a result ld sees the above sequence '-m -Wl,-soname' and treats # '-Wl,-soname' as the emulation mode argument to '-m' I have no idea why make is called differently in both logfiles. Afaik in the lirc ebuild the inherited 'linux-mod' eclass provides a default 'src_compile' function which calls 'linux-mod_src_compile' which then calls eval "emake ... LDFLAGS=\"$(get_abi_LDFLAGS)\" ..." which in turn results in the above make call. However, checking the history of /usr/portage/eclass/linux-mod.eclass I found that the LDFLAGS line was introduced in version 1.79 from 2008! Likewise, 'get_abi_LDFLAGS' from multilib.eclass seems to be out of question as the cause for this bug. Still, I simply disabled 'get_abi_LDFLAGS' in my patched ebuild by redefining it to be empty, and lirc compiles and works. All in all I have no idea whats going on here. Regards, Womble Created attachment 302083 [details, diff]
patched ebuild with disabled get_abi_LDFLAGS
Ran into this bug two months and I don't know how many kernel versions ago. Can we finally get this resolved? Yea please fix it! Confirmed on current amd64 profile. This one was (at least) already reported in Bug 160134, Bug 218717 and Bug 396537 I hate to post "Me too" comments, but this bug is unresolved for *way* too much time. When will this be in the tree? app-misc/lirc-0.8.7 "stable" is also affected by this! /bin/sh ../libtool --tag=CC --mode=link x86_64-pc-linux-gnu-gcc -msse3 -fomit-frame-pointer -O2 -version-info 2:1:2 -m elf_x86_64 -o liblirc_client.la -rpath /usr/lib64 lirc_client.lo libtool: link: x86_64-pc-linux-gnu-gcc -shared -fPIC -DPIC .libs/lirc_client.o -msse3 -O2 -m -Wl,-soname -Wl,liblirc_client.so.0 -o .libs/liblirc_client.so.0.2.1 /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../x86_64-pc-linux-gnu/bin/ld: unrecognised emulation mode: -Wl,-soname Supported emulations: elf_x86_64 elf_i386 i386linux elf_l1om collect2: ld returned 1 exit status make[2]: *** [liblirc_client.la] Erreur 1 make[2] : on quitte le répertoire « /var/tmp/portage/app-misc/lirc-0.8.7/work/lirc-0.8.7/tools » (In reply to comment #13) > Created attachment 302083 [details, diff] [details, diff] > patched ebuild with disabled get_abi_LDFLAGS I just ran into this myself. Applying the patch, from comment I'm replying to, fixed it for me. *** This bug has been marked as a duplicate of bug 160134 *** Almost four month later I hit this bug again at a new system, it would be really good if the patched version of lirc could enter the main portage tree. If comment 28 says that this bug is not a duplicate of bug 160134 https://bugs.gentoo.org/show_bug.cgi?id=160134#c28 , then this bug should be reopened. |