Re: libtool 2.2.10: dependend library concurrency and -L flags order

[Sergei Steshenko]

--- On Tue, 9/21/10, Ingo Krabbe <address@hidden> wrote:

> From: Ingo Krabbe <address@hidden>
> Subject: libtool 2.2.10: dependend library concurrency and -L flags order
> To: address@hidden
> Date: Tuesday, September 21, 2010, 6:35 AM
> 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
> 


Please see https://bugzilla.gnome.org/show_bug.cgi?id=624471 - closer to the 
end.

Regards,
  Sergei.