Re: gtk+-3 trunk compilation as documented in gtk-doc and libtool quick-fix

[Ingo Krabbe]

On Tue, Sep 28, 2010 at 07:56:24PM +0200, Ralf Wildenhues wrote:
> Hello Ingo,
> 
> thanks for the report.
> 
> * Ingo Krabbe wrote on Tue, Sep 28, 2010 at 10:07:44AM CEST:
> > The problem with both of those programs was, that the libtool link
> > wrapper had build a LD_LIBRARY_PATH that contained the system directory
> > "/usr/lib64" before "$prefix/lib", as it found as a sub-dependency of
> > the local gtk-x11.la and gdk-x11.la, some global .la files such as
> > libXinerama.la, before the more local ones libpangocairo*.la for
> > example.
> > 
> > And that how the LD_LIBRARY_PATH of the wrapper has been built, not
> > obeying the link order given by -L and -R flags, that have been
> > calculated in the right order.
> 
> Can you please send the build output for those programs, I'd especially
> be interested in the 'libtool --mode=link' command lines for the
> programs, and all output they generate.
> 
> Even better would be a small reproducible example.
> 
> Is this on GNU/Linux?
> 
> > As I hope this helps you further, I want to provide that patch against
> > libtool, and I hope that it will make into libtool development or is a
> > good anchor point to modify libtool in a different way.
> 
> Well, for a patch we definitely need something reproducible.
> The patch itself has problems too (BTW, it is easier to comment on if
> you send it inline or with text/x-patch or text/plain); see below.

Sorry, I will try to remember, next time I send a patch.

> 
> Instead of the patch, I'm guessing that the actual problem lies
> somewhere else completely: libtool thinks /usr/lib64 isn't in
> sys_lib_search_path_spec or not in sys_lib_dlsearch_path_spec.
> Can you try out the following for me:
> 
> If your generated libtool script does not list /usr/lib64 in these
> variables, add it there please and rebuild.  If generated .la files
> (either from your build, or from previously installed libraries you
> link against) contain -L/usr/lib64 entries, they are most likely all
> wrong, too, and should be removed.  I'm guessing that these two changes
> will fix your build.
> 

I hope that you are fine with such a big package as gtk+-3, as its
currently my own example I have.  What actually happens is: A library
(glib) contains a new symbol but no new version name.  The development
version I link against is in $prefix/lib, while the system version is
in /usr/lib64 (btw, yes GNU/Linux).

The programs link fine, but the wrapper is wrong in using the /usr/lib64
version, while it should use the $prefix/lib version.

Actually I fear, from reading the libtool code, that
sys_lib_search_path_spec and sys_lib_dlsearch_path_spec aren't used in
the wrapper code anyway, and actually both variables actually contain
/usr/lib64 in my libtool script (version 2.2.10 from the system):

--- quote ---
# Compile-time system search path for libraries.
sys_lib_search_path_spec="/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.4
/usr/lib64 /lib64 /usr/x86_64-pc-linux-gnu/lib "

# Run-time system search path for libraries.
sys_lib_dlsearch_path_spec="/lib /usr/lib /usr/local/lib
/usr/x86_64-pc-linux-gnu/lib //usr/lib32/opengl/nvidia/lib
/usr/lib64/opengl/nvidia/lib /lib /usr/lib /lib64 /usr/lib64
/usr/local/lib64 /lib32 /usr/lib32 /usr/local/lib32
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.4
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.4/32
/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4
/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.4/32 //usr/lib64/xulrunner-1.9.2
/usr/lib64/qca2 /usr/lib/qt4 /usr/lib64/qt4 /usr/lib32/qt4
/usr/games/lib /usr/games/lib64 /usr/games/lib32 /usr/lib64/R/lib "
--- END quote ---


Here is the link statement for gtk/gtk-query-immmodules-3.0 and the
resulting compiler command:

--- quote ---
/bin/sh ../libtool  --tag=CC   --mode=link gcc -std=gnu99
-DGDK_PIXBUF_DISABLE_DEPRECATED -DG_DISABLE_DEPRECATED -g -O2 -Wall   -o
gtk-query-immodules-3.0 queryimmodules.o libgtk-x11-3.0.la
../gdk/libgdk-x11-3.0.la -pthread -L/home/ingo/Software/usr/lib
-lpangocairo-1.0 -lX11 -lXcomposite -lXdamage -lXfixes -latk-1.0
-lcairo-gobject -lcairo -lgdk_pixbuf-2.0 -lm -lpng14 -lgio-2.0
-lpangoft2-1.0 -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0
-lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0

libtool: link: gcc -std=gnu99 -DGDK_PIXBUF_DISABLE_DEPRECATED
-DG_DISABLE_DEPRECATED -g -O2 -Wall -o .libs/gtk-query-immodules-3.0
queryimmodules.o -pthread  ./.libs/libgtk-x11-3.0.so
-L/home/ingo/Software/usr/lib -L/lib64 -L/usr/lib64 -L/usr/lib64/qt4
-L/usr/lib
/home/ingo/Software/gtk-devel/gtk+/gdk/.libs/libgdk-x11-3.0.so
../gdk/.libs/libgdk-x11-3.0.so /usr/lib64/libXinerama.so
/usr/lib64/libXi.so /usr/lib64/libXrandr.so /usr/lib64/libXcursor.so
/home/ingo/Software/usr/lib/libpangocairo-1.0.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-gobject.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
/home/ingo/Software/usr/lib/libgdk_pixbuf-2.0.so /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
/usr/lib64/libexpat.so /home/ingo/Software/usr/lib/libgobject-2.0.so
/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
--- END quote ---

Anything is fine, as the -L$prefix/lib here: -L/home/ingo/Software/usr/lib
is used before the other library paths.  Thats how its expected (in my
sight).

But then the wrapper gets called later in the build:

--- quote ---
../../gtk/gtk-query-immodules-3.0 im-am-et.la im-cedilla.la
im-cyrillic-translit.la  im-inuktitut.la im-ipa.la im-multipress.la
im-thai.la im-ti-er.la im-ti-et.la im-viqr.la im-xim.la >
immodules.cache
/home/ingo/Software/gtk-devel/gtk+/gtk/.libs/gtk-query-immodules-3.0:
symbol lookup error:
/home/ingo/Software/gtk-devel/gtk+/gtk/.libs/libgtk-x11-3.0.so.0:
undefined symbol: g_cclosure_marshal_VOID__VARIANT
--- END quote ---

This comes from the LD_LIBRARY_PATH calculated:
    
LD_LIBRARY_PATH="/home/ingo/Software/gtk-devel/gtk+/gtk/.libs:/home/ingo/Software/gtk-devel/gtk+/gdk/.libs:/usr/lib64:/home/ingo/Software/usr/lib:/usr/lib64/qt4:$LD_LIBRARY_PATH"

from gtk/gtk-query-immodules-3.0.

I debugged the creation of the LD_LIBRARY_PATH in the libtool script
with some echo commands and could see loop states, where /usr/lib64 has
been added.

My patch addresses the difference between the calculated compiler
command, especially its -L options and adds these paths to
LD_LIBRARY_PATH after the paths relative to the package build directory,
so that the wrapper script perfectly reflects the order of library
searches as the compiler sees them.

Its hard to solve this once for all, but I think this is still the best
way to do it, though there might be some smarter solutions.  I haven't
cared yet about the side effects on $sysroot compilations, or off source
builds, but I think there are quite safe too, so I currently cannot see
the problems coming from my solution.  Maybe some systems not having sed
and tr might need some love (if they are targeted anyway).

Another much more complex solution might be to order the build paths by
preference and put them together later:

1- build directory
2- prefix
3- system libraries

(kind of).

The patch works for this example and gtk+-3 builds fine now from
origin/master.

I hope this is a working example for you, as it would be quite some work
to build a small example from scratch.

If I got it right the patch also addresses the problem from bug
http://savannah.gnu.org/support/?107416

bye ingo