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

[Ralf Wildenhues]

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.

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.

Just for the record:

> --- a/libltdl/config/ltmain.m4sh
> +++ b/libltdl/config/ltmain.m4sh
> @@ -4356,6 +4356,10 @@ func_mode_link ()
>      xrpath=
>      perm_rpath=
>      temp_rpath=
> +    nl_add=    # nl_add will contain a converted newlib_search_path
> +               # to be added to temp_rpath for the wrapper
> +    abs_base=$(cd `dirname $0` && pwd) # this is used to check if a path is

unfortunately, $(cmd) command substitution is not something we can
portably rely on just yet.  libtool has func_dirname and progpath
instead of dirname and $0.

This heuristic will fail in packages that contain sub-configure scripts,
IOW a package hierarchy, where you may link against uninstalled
libraries from sibling packages.

> +                                       # relative to our build directory
>      thread_safe=no
>      vinfo=
>      vinfo_number=no
> @@ -5839,6 +5843,15 @@ func_mode_link ()
>                test -z "$old_library"; }; then
>             # We need to hardcode the library path
>             if test -n "$shlibpath_var" && test -z "$avoidtemprpath" ; then
> +             # quick and dirty patch to obey -L and -R options in the wrapper
> +             # script
> +             if [ -z "$nl_add" ]; then case "$absdir" in
> +               *"$abs_base"*) ;; # when we leave the build base
> +               *)                # we will simply add newlib_search_path
> +                 nl_add=$(printf "$newlib_search_path"| sed -e "s/ 
> *\(.*\)$/\1/"|tr \\040 :)

See above on $(...)
printf interprets its argument; inside libtool, use $ECHO, and
elsewhere, use
  printf "%s\n" ...

\040 is ASCII-specific.


> +                 temp_rpath+="$nl_add:"

+= is bash-specific.  (The generated libtool script contains them only
if we know we're running bash.)

> +                 ;;
> +             esac fi
>               # Make sure the rpath contains only unique directories.
>               case "$temp_rpath:" in
>               *"$absdir:"*) ;;

Hope that helps.

Cheers,
Ralf