Summary: | app-misc/lirc-0.8.6-r2 does not respect LDFLAGS | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Doktor Notor <notordoktor> |
Component: | New packages | Assignee: | Television related Applications in Gentoo's Portage <media-tv> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | esigra, kernel-misc, Thomas.Rausch |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 331933 |
Description
Doktor Notor
2010-03-19 11:21:22 UTC
Which version? Well, the above is with the latest app-misc/lirc-0.8.6-r2 (no point to report similar bugs against old ones) but all versions fail in this respect pretty likely. Build system of lirc is perfectly sane and respects LDFLAGS. It's linux-mod.eclass that's causing this. default src_compile look like that: emake ... LDFLAGS="$(get_abi_LDFLAGS)" ... I don't know whether it's intended behaviour. I see two ways of fixing it: 1. change linux-mod.eclass 2. use handcrafted src_compile instead of default linux-mod_src_compile CCing kernel-misc to consider 1. sounds like LDFLAGS="$(get_abi_LDFLAGS)" should be LDFLAGS="${LDFLAGS} $(get_abi_LDFLAGS)" instead in the eclass Considering that this affects any ebuild using default src_compile from linux-mod.eclass and actually installs anything beyond kernel modules, fixing this in ebuilds doesn't make sense. Actually yes it does, because most of lirc shouldn't be build from linux-mod.eclass but on its own. Fixed in lirc-0.9.0-r1 Also, this is essentially a duplicate of bug 160134 , since the reason for that bug was that LDFLAGS were being overridden by linux-mod.eclass also. |