[Top][All Lists]

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

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

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

On Tue, Sep 21, 2010 at 08:02:28AM -0700, Sergei Steshenko wrote:
> --- 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
> > 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.

Hello Sergei,

yes that's quite the same bug.  But still I cannot see a solution there.

I also found http://savannah.gnu.org/support/?107416 to handle a similar
more abstract topic.  It all comes out that there needs some possibility
to tune, filter or order the PATHS that are evaluated by libtool to find
the paths that lead to a binary.

As this is close to the build process the link stage should be able to
find a valid order of libraries by command line arguments too.

To get back into my example lets take a look into gtk3-scan again:

                /bin/sh ../../../libtool --tag=CC --mode=link gcc -std=gnu99
        -Wall gtk3-scan.lo ../../../gdk/libgdk-x11-3.0.la
        ../../../gtk/libgtk-x11-3.0.la  -o gtk3-scan

leads to

                libtool: link: gcc -std=gnu99 -DGDK_PIXBUF_DISABLE_DEPRECATED
        -DG_DISABLE_DEPRECATED -g -O2 -Wall .libs/gtk3-scan.o -o
        .libs/gtk3-scan ../../../gdk/.libs/libgdk-x11-3.0.so
        -L/home/ingo/Software/usr/lib -L/lib64 -L/usr/lib64
        -L/usr/lib64/qt4 -L/usr/lib ../../../gtk/.libs/libgtk-x11-3.0.so
        /usr/lib64/libXinerama.so /usr/lib64/libXi.so
        /usr/lib64/libXrandr.so /usr/lib64/libXcursor.so
        /usr/lib64/libXcomposite.so /usr/lib64/libXext.so
        /usr/lib64/libXdamage.so /usr/lib64/libXfixes.so
        /home/ingo/Software/usr/lib/libatk-1.0.so /usr/lib64/libcairo.so
        /usr/lib64/libpixman-1.so /usr/lib64/libXrender.so
        /usr/lib64/qt4/libQtGui.so /usr/lib64/qt4/libQtCore.so
        /usr/lib64/libX11.so /usr/lib64/libxcb.so /usr/lib64/libXau.so
        /usr/lib64/libXdmcp.so -lGL -lEGL
        /usr/lib64/libpng14.so /home/ingo/Software/usr/lib/libgio-2.0.so
        -lresolv /home/ingo/Software/usr/lib/libpangoft2-1.0.so
        /home/ingo/Software/usr/lib/libpango-1.0.so -lm
        /usr/lib64/libfontconfig.so /usr/lib64/libfreetype.so -lz
        /home/ingo/Software/usr/lib/libgmodule-2.0.so -ldl
        /home/ingo/Software/usr/lib/libgthread-2.0.so -lpthread -lrt
        /home/ingo/Software/usr/lib/libglib-2.0.so -lpcre -pthread
        -Wl,-rpath -Wl,/home/ingo/Software/usr/lib

Analysing the build link stage that produces the correct result, the
LD_LIBRARY_PATH is built from the order the .so files are mentioned

        /usr/lib64/libXinerama.so /usr/lib64/libXi.so
        /usr/lib64/libXrandr.so /usr/lib64/libXcursor.so

we see the local paths three times followed by four /usr/lib64 files
followed by a prefix (DESTDIR) installation.

But actually the linker stage should honor the order the -L options:


So a good result should follow the rule, the linker does:

        1. local paths
        2. -L library paths
        3. system paths

We should fix libtool that way, that relative paths and absolute paths
below "build root" should take first precedence followed by -rpath options,
followed by -L options, finally followed by all the rest.

That should give us the right order of libraries as the linker and the
resulting/relinked binary sees it.  Did I made some error here?

bye ingo

> Regards,
>   Sergei.

Attachment: pgpu9_HdLE5SN.pgp
Description: PGP signature

reply via email to

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