[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
dependend library concurrency and -L flags order
From: |
Ingo Krabbe |
Subject: |
dependend library concurrency and -L flags order |
Date: |
Tue, 21 Sep 2010 15:31:53 +0200 |
User-agent: |
Mutt/1.5.20 (2009-06-14) |
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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- dependend library concurrency and -L flags order,
Ingo Krabbe <=