[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnash-dev] libtool and dependencies pollution
From: |
strk |
Subject: |
[Gnash-dev] libtool and dependencies pollution |
Date: |
Fri, 28 Jul 2006 15:29:04 +0200 |
I've been struggling to build gnash with the latest
gstreamer release for about the whole week.
This are my current findings.
My main problem turned out to be a forced -L/usr/lib
I did update lots of macros to make sure gnash doesn't
add -L/usr/lib itself, still, libtool introduces it.
It seems that -L/usr/lib is found in a *lot* of .la
files installed system-wide, so that's probably where
libtool takes it from.
The final problem is that I have an older libglib-2.0
installed in /usr/lib and a *new* libglib-2.0 installed
in a custom dir (the new glib version was required by
gstreamer-0.10.9).
So, what happens is that -lglib-2.0 ends up linking
against the version in /usr/lib instead that in the
version of my custom install.
Since stripping -L/usr/lib seems an impossible goal
(we don't want to skip parsing of .la files from libtool)
the only chance seems to be making sure that our own
custom LDFLAGS are *prepended* to the ones automatically
added by libtool.
I think there was a discussion about libtool upgrade
in the past, maybe this is the right time to get it in,
or does anybody has suggestions on how to force that behaviour ?
--strk;
PS: I know, overriding /usr/lib with the new glib version seems
a simpler approach, but I don't think builders should be forced
to use a specific layout.
- [Gnash-dev] libtool and dependencies pollution,
strk <=