On Dec 23, 2008, at 9:06 PM, Duane Ellis wrote:
rick> Personally a find the use of rpath a horrible direction for us to go. Shared libraries encode their install location as part of the binary. rick> [elsewhere] If libftdi is built with --prefix, its install path in the binary will be correct and everything is fine. No rpath is necessary.Since when? Perhaps you know something I do not know. Please point me to a reference.
If you use configure with --prefix and do a 'make install', the resulting binary has the correct install path encoded. Otherwise, my build of libftdi on OS X via MacPorts would break since it build libftdi into /opt/local. It certainly doesn't use rpath for that. To see for yourself, build libftdi with --prefix set to something strange like /var/tmp. After a 'make', run ldd on the binary and it should tell you the install path that was encoded. This is also how I build the GNU toolchain into /usr/local/arm without rpath.
I have used -rpath exactly to solve the problem when a package is installed in a non-standard place. and that is exactly the problem we are discussing, and why it would be used in that scenario.
Installing to a non-standard location isn't a problem as long as -- prefix is used and 'make install' is used to install the bits. rpath comes into play if the encoded install path for the .so is different from the actual path on disk. That only happens if you manually move the .so or if you do funny things like 'make install DSTROOT=...'.
In fact, numerous GNU tools tell you to do exactly this. MPFR and GMP are two exact examples of this.See for example the MPFR manual, section 4.1 - here: http://www.mpfr.org/mpfr-current/mpfr.html Last paragraph.
The reference there is pretty light on details. "on some system" you "may" need to use path. The only cases I can think of are if you installed to a location different from the configure --prefix path via DSTROOT. OS X tends to encode the full path in the binary, but if you encode _only_ the filename and it is in a non-standard location, you would need to use rpath, but that is not a normal case and would require additional work to force the encoded path to be only the filename.
I suggest trying to build libftdi with --prefix into a location such as /opt/local or /var/tmp. After it is built and installed, a simple test program should link and run as long as -L<path> and -lftdi are passed.
-Duane.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
