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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
