In regard to: libtool on solaris and hard coding the rpath, Liam Hoekenga...: > % ldd libphp4.so > libpam.so.1 => /usr/lib/libpam.so.1 > libdl.so.1 => /usr/lib/libdl.so.1 > libsocket.so.1 => /usr/lib/libsocket.so.1 > libnsl.so.1 => /usr/lib/libnsl.so.1 > libresolv.so.2 => /usr/lib/libresolv.so.2 > libm.so.1 => /usr/lib/libm.so.1 > libclntsh.so.8.0 => (file not found) > libc.so.1 => /usr/lib/libc.so.1 > libmp.so.2 => /usr/lib/libmp.so.2 > >Is there any way to actually get libtool (on Solaris) to hardcode the >rpath into shared libraries (in addition to any program binaries it might >be used to generate)? I'm not sure what the libtool maintainers policy on this particular issue is, but I've always preferred to have the RPATH hardcoded into libraries as well, especially on platforms like Tru64 UNIX and IRIX, where the apps automatically pick up that RPATH when they link with the library (so you don't need to worry about specifying an RPATH when you link the app, only when you build the libraries). Solaris is a bit more of a pain, but that's Solaris. :-) I have a patch that really saves me some work with Tru64 and IRIX, but I'm not sure it wins me anything on Solaris, since even if you build a DT_RPATH into a library there, the apps generally don't pick it up from the library. You do know about the LD_RUN_PATH environment variable that the Solaris linker will honor, though, right? You could use that to hardcode your DT_RPATH with `libtool' being none the wiser, I think. Tim _______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
