bug-libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

mixed prefix libraries ...


From: Michael Meeks
Subject: mixed prefix libraries ...
Date: Fri, 25 Jun 2010 16:57:38 +0100

Hi guys,

        I'm having problems running libtool linked binaries inside my build
environment. This is related [ I believe ] to conflicts between system
versions of libraries vs. those installed on my prefix.

        As an example, I have two glib libraries:

        /usr/lib/libglib-2.0.so -> libglib-2.0.so.0.2200.5
        /opt/hgnome/lib/libglib-2.0.so -> libglib-2.0.so.0.2511.0

        And I compile an input module inside gtk+. Linking works perfectly,
unfortunately when the libtool wrapper comes to execute, it tries to
setup LD_LIBRARY_PATH to mean that we get the right library - which is
great.

        Unfortunately, when we link the input module; we link to a .la file
first, and then the various libraries; approximately:

LDADDS = ... \
$(top_builddir)/libgtk-x11-$(GTK_API_VERSION).la
-L/opt/hgnome/lib -lglib-2.0 -l...

        Unfortunately, we have .la files for many of the dependents of this gtk
+ library, including a bus-load of X libraries installed into /usr/lib.

        These in turn cause $temp_rpath to have /usr/lib: prepended to the
LD_LIBRARY_PATH before /opt/hgnome/lib.

        This causes the wrong glib to be linked to when the libtool wrapper
script is called.

        Sooo ... my thought is: why do we have this rather complicated setup of
walking .la files trying to find the right paths etc. ? why do we even
try to use a complex LD_LIBRARY_PATH ?

        Would it not be rather easier, wherever possible, to create symlinks
for the correct (individual) libraries into .libs - and have a single
LD_LIBRARY_PATH entry for that directory ?

        That way we would have a more robust solution, with full control over
which libraries to link from what prefix.

        Failing that it is unclear to me why linking works but running does
not ;-) how can it be that we manage to get the right paths linked into
the .libs/gtk-query-immodules binary and then break them with these
extra LD_LIBRARY_PATH that (apparently) are not really necessary ?

        I hope the description is accurate enough; apologies if not.

        Thanks,

                Michael.

-- 
 address@hidden  <><, Pseudo Engineer, itinerant idiot





reply via email to

[Prev in Thread] Current Thread [Next in Thread]