The ebuild sets GECKO_SDK to /usr/lib/MozillaFirefox, should be /usr/lib/mozilla-firefox. Reproducible: Always Steps to Reproduce: 1.USE="firefox mozilla" emerge swt Actual Results: cc1plus: /usr/lib/MozillaFirefox/include/mozilla-config.h: No such file or directory Expected Results: >>> Regenerating /etc/ld.so.cache... >>> dev-java/swt-3.1 merged.
Created attachment 64118 [details] Fixed ebuild
(In reply to comment #1) > Created an attachment (id=64118) [edit] > Fixed ebuild > It is better to attach diffs against the current ebuild so we can quickly see what is changed. I don't know if this has anything to do with this but this is the latest change in mozilla-firefox: *mozilla-firefox-1.0.6-r2 (23 Jul 2005) 23 Jul 2005; Jory A. Pratt <anarchy@gentoo.org> files/10MozillaFirefox, -mozilla-firefox-1.0.6-r1.ebuild, +mozilla-firefox-1.0.6-r2.ebuild: update for 10MozillaFirefox lib dir
Ah yes. It seems that the swt ebuild has hardcoded the path to firefox. I think it would be better to come up with a solution that works with both the old and new path. The path to firefox is in for example /etc/env.d/10MozillaFirefox.
/etc/env.d/10MozillaFirefox contains the ldpath but the header files are in another directory so it's unfortunatly not usable here. And here's a pseudo diff for those who havn't compared it to the original yet. Sorry for not posting it originaly: -- GECKO_SDK=/usr/lib/MozillaFirefox ++ GECKO_SDK=/usr/lib/mozilla-firefox
The ldpath in /etc/env.d/10MozillaFirefox has been updated from firefox 1.06-r2 so it could be used to find the headers now.
Using the LD_LIBRARY_PATH for the headers IMO is bad. That env variable is meant to be used for libraries not for headers.
Fixed this in -r1. Please retry emerging it in about an hour and reopen the bug if the problem persists.
