Bug 151512 - games-simulation/flightgear-0.9.10 - undefined symbol: alutLoadWAVFile
|
Bug#:
151512
|
Product: Gentoo Linux
|
Version: unspecified
|
Platform: AMD64
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: major
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: games@gentoo.org
|
Reported By: michael@kjorling.com
|
|
Component: Games
|
|
|
URL:
|
|
Summary: games-simulation/flightgear-0.9.10 - undefined symbol: alutLoadWAVFile
|
|
Keywords:
|
|
Status Whiteboard:
|
|
Opened: 2006-10-15 14:59 0000
|
flightgear-0.9.10 has a runtime dependency on media-libs/freealut (specifically
any library providing AL/alut.h) which is not listed in the ebuild. This causes
a compile-time failure and inability to start the game by issuing the command
fgfs, the latter failing during or immediately after "initializing subsystems"
with the following error on stderr:
fgfs: symbol lookup error: fgfs: undefined symbol: alutLoadWAVFile
As flightgear (even 0.9.10) worked for me before, this looks like a mistake in
updating the fg ebuild, or a related one. Is virtual/glut supposed to provide
ALUT?
The patch below fixes this on my system (using the default-linux/amd64/2005.0
profile) but admittedly is something of a kludge.
--- /usr/portage/games-simulation/flightgear/flightgear-0.9.10.ebuild
2006-04-08 03:45:49.000000000 +0200
+++ /usr/local/portage/games-simulation/flightgear/flightgear-0.9.10.ebuild
2006-10-15 23:35:40.000000000 +0200
@@ -19,7 +19,8 @@
RDEPEND="virtual/glut
~dev-games/simgear-0.3.10
- >=media-libs/plib-1.8.4"
+ >=media-libs/plib-1.8.4
+ media-libs/freealut"
DEPEND="${RDEPEND}
>=sys-apps/sed-4"
Hardcoding dependency on media-libs/freealut is not acceptable; that's the
whole point of virtual/glut.
(In reply to comment #1)
> Hardcoding dependency on media-libs/freealut is not acceptable; that's the
> whole point of virtual/glut.
(In reply to comment #2)
> freealut isn't glut
Frankly, I don't care what virtual ebuilds provide which specific packages.
(virtual/glut obviously does not pull in media-libs/freealut, or ALUT would
have been on my system; looking at the ebuild file also confirms this) I just
want the applications I have emerged previously - from source, even - to keep
working. There is no need to tell me that the exact steps I took to correct on
my own system what is obviously a portage tree deficiency are "not acceptable".
If you have a better solution that should go into the official tree, that is
perfectly fine by me. The patch I included should indicate clearly enough that
the modified ebuild is from a portage overlay, not in the official tree.
simgear depends on freealut so that should be enough
I hate implicit deps. I'll add this since it'll break installs where simgear
comes from a binpkg and flightgear is being compiled. We run into this sort of
thing all the time with Release Engineering and it makes me want to tsab people
who use implicit deps.
OK. It actually isn't an implicit dependency. It is a required runtime
dependency.
FIXED in CVS...
