Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 160134 - app-misc/lirc: compiler for driver is invoked with raw linker flags (LDFLAGS) - ld: unrecognised emulation mode: -Wl,-soname
Summary: app-misc/lirc: compiler for driver is invoked with raw linker flags (LDFLAGS)...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: AMD64 Linux
: High normal with 5 votes (vote)
Assignee: Television related Applications in Gentoo's Portage
URL:
Whiteboard:
Keywords:
: 216145 218717 396537 396653 417645 417893 419447 (view as bug list)
Depends on: 284840
Blocks: lirc-tracker
  Show dependency tree
 
Reported: 2007-01-04 16:24 UTC by Mike Benson
Modified: 2012-07-22 15:24 UTC (History)
29 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
emerge --info (emerge--info.txt,4.14 KB, text/plain)
2007-01-04 16:28 UTC, Mike Benson
Details
Complete ebuild log, showing error (app-misc:lirc-0.8.0-r8:20070105-001310.log,30.21 KB, text/plain)
2007-01-14 18:39 UTC, Mike Benson
Details
emerge --info (emerge.nfo,4.44 KB, text/plain)
2007-01-29 23:37 UTC, christian
Details
lirc failed ebuild (lirc-failed-ebuild.nfo,28.20 KB, text/plain)
2007-01-29 23:46 UTC, christian
Details
Patch to fix lirc-0.9.0.ebuild (lirc-0.9.0.ebuild.diff,1.82 KB, patch)
2012-04-30 07:09 UTC, Steven Newbury
Details | Diff
/var/tmp/portage/app-misc/lirc-0.9.0/temp/lirc-0.9.0.ebuild.diff.out (lirc-0.9.0.ebuild.diff.out,2.62 KB, text/plain)
2012-06-09 10:36 UTC, Juergen Rose
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Benson 2007-01-04 16:24:03 UTC
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
Comment 1 Mike Benson 2007-01-04 16:28:16 UTC
Created attachment 105434 [details]
emerge --info
Comment 2 Matthias Schwarzott gentoo-dev 2007-01-06 11:10:26 UTC
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.
Comment 3 Matthias Schwarzott gentoo-dev 2007-01-14 17:16:32 UTC
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.
Comment 4 Mike Benson 2007-01-14 18:39:46 UTC
Created attachment 106982 [details]
Complete ebuild log, showing error
Comment 5 christian 2007-01-29 23:33:23 UTC
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.
________________________________________________

Comment 6 christian 2007-01-29 23:37:35 UTC
Created attachment 108553 [details]
emerge --info
Comment 7 christian 2007-01-29 23:46:50 UTC
Created attachment 108554 [details]
lirc failed ebuild
Comment 8 christian 2007-01-30 00:03:23 UTC
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."
Comment 9 Mike Benson 2007-05-09 14:00:49 UTC
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.
Comment 10 Mike Benson 2007-05-29 02:57:13 UTC
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!
Comment 11 Mike Benson 2007-05-29 05:09:34 UTC
(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?
Comment 12 Joseph Turian 2007-09-18 04:01:28 UTC
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?
> 

Comment 13 Carsten Lohrke (RETIRED) gentoo-dev 2008-04-04 17:05:53 UTC
*** Bug 216145 has been marked as a duplicate of this bug. ***
Comment 14 Matthias Schwarzott gentoo-dev 2008-05-06 07:56:58 UTC
Does lirc-0.8.3 still have this bug?
Comment 15 Mike Benson 2008-06-01 19:44:29 UTC
(In reply to comment #14)
> Does lirc-0.8.3 still have this bug?
> 
lirc-0.8.3-r2 does.
Comment 16 Jory A. Pratt gentoo-dev 2009-09-13 23:31:19 UTC
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.
Comment 17 Francisco Blas Izquierdo Riera gentoo-dev 2009-09-13 23:38:26 UTC
After upgrading to the 10.0 profile worked for me on AMD64/multilib :)
Comment 18 Gordon Malm (RETIRED) gentoo-dev 2009-09-14 04:07:21 UTC
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.
Comment 19 Magnus Granberg gentoo-dev 2010-07-27 17:04:52 UTC
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.
Comment 20 Federico Cuello 2011-12-11 19:07:35 UTC
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
Comment 21 Adam Stylinski 2011-12-14 05:25:27 UTC
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).
Comment 22 Vu Tran Kien 2012-01-05 13:15:48 UTC
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!
Comment 23 Elijah "Armageddon" El Lazkani (amd64 AT) 2012-03-18 01:57:45 UTC
Please do not CC arches on your own
Comment 24 Martin DiViaio 2012-03-19 16:44:24 UTC
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
Comment 25 Christian Ruppert (idl0r) archtester Gentoo Infrastructure gentoo-dev Security 2012-04-13 03:28:56 UTC
*** Bug 218717 has been marked as a duplicate of this bug. ***
Comment 26 Christian Ruppert (idl0r) archtester Gentoo Infrastructure gentoo-dev Security 2012-04-13 03:29:22 UTC
*** Bug 396537 has been marked as a duplicate of this bug. ***
Comment 27 Christian Ruppert (idl0r) archtester Gentoo Infrastructure gentoo-dev Security 2012-04-13 03:29:49 UTC
*** Bug 396653 has been marked as a duplicate of this bug. ***
Comment 28 SpanKY gentoo-dev 2012-04-13 13:14:31 UTC
(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.
Comment 29 Steven Newbury 2012-04-30 07:09:01 UTC
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.
Comment 30 CBke -Left- bye 2012-05-19 03:55:47 UTC
(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
Comment 31 Jeroen Roovers (RETIRED) gentoo-dev 2012-05-28 00:50:52 UTC
*** Bug 417893 has been marked as a duplicate of this bug. ***
Comment 32 Jeroen Roovers (RETIRED) gentoo-dev 2012-05-28 00:51:06 UTC
*** Bug 417645 has been marked as a duplicate of this bug. ***
Comment 33 Dominique Michel 2012-05-29 14:59:46 UTC
Same problem here on ~amd64 profile desktop and MAKEOPTS="-j5" in make.conf. To run emerge with MAKEOPTS="-j1" work for me.
Comment 34 Dominique Michel 2012-05-29 15:02:42 UTC
(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.
Comment 35 László Szalma 2012-06-01 17:43:30 UTC
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.
Comment 36 Juergen Rose 2012-06-09 10:35:50 UTC
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 )
Comment 37 Juergen Rose 2012-06-09 10:36:54 UTC
Created attachment 314769 [details]
/var/tmp/portage/app-misc/lirc-0.9.0/temp/lirc-0.9.0.ebuild.diff.out
Comment 38 Sergey Popov gentoo-dev 2012-06-11 06:32:31 UTC
(In reply to comment #29)

Your patch works for me too. Thanks!
Comment 39 Steven Newbury 2012-06-12 22:04:42 UTC
(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.
Comment 40 Christian Schmidt 2012-06-17 14:25:06 UTC
(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.
Comment 41 Marc Tousignant 2012-07-03 16:03:35 UTC
(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.
Comment 42 Gregg Casillo 2012-07-10 19:19:30 UTC
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?
Comment 43 Ian Stakenvicius gentoo-dev 2012-07-17 19:21:16 UTC
+*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.
Comment 44 Ian Stakenvicius gentoo-dev 2012-07-18 13:00:31 UTC
*** Bug 419447 has been marked as a duplicate of this bug. ***
Comment 45 László Szalma 2012-07-22 15:24:11 UTC
Compiles and works fine! Thank You.