Re: gtk+-3 trunk compilation as documented in gtk-doc and libtool quick-fix
- From: Ralf Wildenhues <Ralf Wildenhues gmx de>
- To: Ingo Krabbe <ikrabbe ask googlemail com>
- Cc: gtk-devel-list gnome org, bug-libtool gnu org
- Subject: Re: gtk+-3 trunk compilation as documented in gtk-doc and libtool quick-fix
- Date: Tue, 28 Sep 2010 17:56:43 -0000
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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]