Dan Winship wrote:
 
> > It was hoped that new packages that use libtool-1.3.4 wouldn't need
> > any special attention at all, but see PR's pkg/9902, and pkg/10106.
> 
> Coincidentally, these were both fixed in the libtool mainline in the
> last few days. But they just missed making it into libtool 1.3.5 which
> came out on Sunday.

  I have now committed libtool-1.3.5 with these patches and am almost
ready to commit the big USE_PKGLIBTOOL change.  Before I do this, I need
one problem solved, however: so far I have been unable to create shared
libraries (using libtool-1.3.5) that have the correct runtime linker
search path set.  I.e., I have not found a way to correctly specify
this, because libtool silently eats any -Wl,-R statements:


libtool --mode=link cc -Wl,-R/usr/X11R6/lib -L/usr/X11R6/lib -o
libtest.la -rpath /usr/X11R6/lib -version-info 3:1:3 glade-gtk.lo -lgtk
-lgdk

ends up doing a

cc -shared  glade-gtk.lo  -L/usr/X11R6/lib -lgtk -lgdk -lc  -Wl,-soname
-Wl,libtest.so.3 -o .libs/libtest.so.3.1

thus, "ldd .libs/libtest.so.3.1" gives me:

.libs/libtest.so.3.1:
         -lgtk.12 => not found
         -lgdk.12 => not found
         -lc.12 => /usr/lib/libc.so.12


  Even if I add explicit '-R <libdir>' options (that are obviously
parsed by libtool), the linker does not receive any '-R' argument. (The
only thing that is accomplished by passing '-R' to libtool is the
addition of '-R' to the .la file for the final link; but this seems to
be too late, because even if the correct library path is set in the
final link of the application program, the runtime linker complains
about the missing libraries.)

  IMHO, the correct approach would be to pass any '-Wl,-R' options to
that 'cc -shared' linker command line (actually, that's what '-Wl' is
for, isn't it? ;-).  Unfortunately, I'm not that much of a libtool
expert, so I'm seeking some advice here.  Ideas, anyone?

  Cheers
      ,
   Rene