bug-libtool
[Top][All Lists]
Advanced

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

libtool 2.2.10: dependend library concurrency and -L flags order


From: Ingo Krabbe
Subject: libtool 2.2.10: dependend library concurrency and -L flags order
Date: Tue, 21 Sep 2010 15:35:40 +0200
User-agent: Mutt/1.5.20 (2009-06-14)

Sorry I forgot that:
libtool (GNU libtool) 2.2.10

So I repeat:
Hi developers,

this is not quite a bug, but more a usage question, that, can't it be
answered easily turns out to be a bug on my side:

I want to compile a libtool driven source code package that is already
installed to my system, as a development test version into another,
local directory.  Actually this is gtk+ with its dependencies and don't
tell me now I need jhbuild for this, as I know that and might find
another example then.

Some binaries during the gtk+3 build are exectuted in a later phase of
the build i.e. docs/references/gtk/gtk3-scan, that is of course a
libtool script then, that points to the properly linked .libs/gtk3-scan
there.

The LD_LIBRARY_PATH calculated by libtool contains two libraries from
the package tree itself, which is usefull, but then it contains
/usr/lib64 before(!) my local build path I used as a prefix
$HOME/my-gtk/usr.

That again means that, the gobject-2.0.so library is included from the
wrong path, as it should be loaded from my local path, containing some
symbols needed here and not available there.

So my question is: How can I control the order of that LD_LIBRARY_PATH?
or better: As I work on a system that perfectly knows to link against
installed libraries, be they where I defined them to be, through -rpath,
which is a well known default in our days, I would be most glad if that
LD_LIBRARY_PATH could be cleaned from any non-local or package specific
path.  I that possible?

TIA ingo



reply via email to

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