I noticed when building a new gentoo 1.4 rc2 system today that anything looking for alsa libs was failing. This may be an alsa only problem. It appears that somewhere along the line, alsa decided to tell anything using it that its libs were in `/var/tmp/portage/alsa-lib<etcetc>/image/usr/lib'. esd for instance took this, and passed the same info on to any app whose compile runs `esd-config --libs'. I grepped /usr/lib for "/var/tmp" and fixed things up, and now things appear to be chugging long nicely. Perhaps portage should check when merging that these things arent in files, and if they are, fix them. Reproducible: Didn't try Steps to Reproduce: 1. 2. 3.
can you be more specific, with package versions, and filenames, etc etc?
well?
Anything that was in portage at the time I posted this bug. I didn't have time to go finding versions or investigating the bug any more at the time, but I know I was building a fresh system with current x86 portage. Default use flags. If I get a chance over the next week, i'll try and reproduce it.
(apologies for comment thrashing) As for file names, it this showed itself in usr/lib/libesd.la, and several others (which I have forgotten), all had libdir set to /var/tmp/portage/alsa-lib-0.90_rc/work/image/usr/lib.
Portage doesn't handle this. I suppose it could, but everything related to files needing to be altered should probably be done by the ebuild. Portage can't really guess at what should be changed. Give it to the alsa guys.
I cannot see the described behaviour. At least not with the alsa libs. agenkin@bashful:/usr/lib$ fgrep /var/tmp/portage *.la liblber.la:dependency_libs=' -L/var/tmp/portage/openldap-2.0.25-r2/work/openldap-2.0.25/libraries' libldap.la:dependency_libs=' -L/var/tmp/portage/openldap-2.0.25-r2/work/openldap-2.0.25/libraries -lssl -lcrypto' libldap_r.la:dependency_libs=' -L/var/tmp/portage/openldap-2.0.25-r2/work/openldap-2.0.25/libraries -lssl -lcrypto' All of the three libraries belong to "net-nds/openldap". Please give more details (portage version, etc.).
*** Bug 17579 has been marked as a duplicate of this bug. ***
To everybody on the CC list that sees this bug: please post more details. I want to know your portage version ("emerge info") and the version of alsa packages that you are trying to build. Also, please try the new stable release of ALSA (0.9.1); it is still masked with ~x86, but not for long.
Is anyone still experiencing this problem?
closing as it works for me, it's old, and I'm getting no response from the submitter on whether or not it's still a problem.
