On Thu, Dec 25, 2008 at 09:16:41AM +0100, Dirk Behme wrote:
> Rick Altherr wrote:
> > On Dec 23, 2008, at 7:50 PM, Duane Ellis wrote:
> >> (b) Secondly, I have to add the "-Wl,-rpath,<DIRNAME>" if we choose
> >> to use the .SO file.
> >> Otherwise - well - openocd will not find the file when you run it.
> >> It will link - due to the "-L", but not *FIND* due to missing '-
> >> rpath'
> >
> > 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.
> > FTDI has built their library with a perfectly acceptable install
> > location encoded in the binary. A user should download the d2xx binary
> > and put the files in the proper installed locations. Hacking up our
> > configure scripts so users can be lazy and FTDI doesn't need to fix
> > their horribly packaged binary is just wrong. I realize we want to
> > appeal to the masses, but if a user is going to compile from source,
> > they should be able to move a few files around.
IIRC libtool uses -rpath so you can run a binary from the build
dir during development. But this means it has to link again
for "make install" to remove the hardcoded path. If you install
using a non-standard --prefix (i.e. not /usr or /usr/local),
you'll usually have to set LD_LIBRARY_PATH to run your app.
I've installed many libs and apps somewhere in my home dir
over the years, and none of them used rpath there, I've
always had to set LD_LIBRARY_PATH. I guess the rationale
is that a binary using rpath breaks when it is moved to
another location, which is usually not acceptable.
So, -rpath has its use but its not necessarily the best tool
to solve the non-standard prefix problem.
BTW, I've never used libftd2xx0 but I just looked at the
libftd2xx0.4.16.tar.gz readme.dat there is a hardcoded
path for the ftd2xx.cfg file. So it needs to be installed
there anyway?
> > If libftdi is built with --prefix, its install path in the binary will
> > be correct and everything is fine. No rpath is necessary.
That doesn't sound right, ld.so needs to find the lib, thus
the path to libftdi cannot be built into libftdi...
If libftdi is not installed in /lib, /usr/lib or one of
the directories listed in /etc/ld.so.conf, you need
LD_LIBRARY_PATH when running openocd (or link openocd with -rpath).
If you want to make it convencient to openocd users to use
a non-standard --prefix it's best to supply a small shell script, e.g.:
#!/bin/sh
# assume script is in $prefix/bin and libs are in $prefix/lib
dir=${0%/*}
LD_LIBRARY_PATH=$dir/../lib
export LD_LIBRARY_PATH
exec $dir/openocd
> Short conclusion from my (limited Linux only) point of view. I think
> for my use cases everything would already be fine
>
> * if for (open source) libftdi path given by --prefix is used by -I
> and -L, too.
>
> * if for (binary) ftd2xx path given by (existing) -with-ftd2xx is
> additonally used by -L
>
> Maybe we can start with these two fixes which are improvements
> already? And then go on with further changes (e.g. introducing
> --with-ftd2xx-win32-zipdir and --with-ftd2xx-linux-tardir ) later in a
> second step on top of this?
IMHO it is good practice to hide differences between platforms
and library versions and handle this inside the configure script.
The canonical use for the --with-ftd2xx option would be:
--with-ftd2xx or --with-ftd2xx=yes search default path (/usr)
--without-ftd2xx or --with-ftd2xx=no don't use libftd2xx
--with-ftd2xx=/some/path search given path
e.g see
http://git.cryp.to/autoconf-archive?a=blob;f=ac_lib_id3.m4;h=baabf6d569b9fbd8b4dfdf7007c40a69be0e549d;hb=HEAD
This could be complemented with --enable-static-ftd2xx if desired.
A few lines of shell script inside configure.in can then detect
the full path for the lib and header file.
The user has the option of installing the lib in a standard place,
or just unpack it and pass the path to --with-ftd2xx=. If the user
wants to install in a non-standard prefix _and_ use the shared
lib then it's the user's responsibility to also intall the shared
library in this prefix and set LD_LIBRARY_PATH.
Johannes
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
