On October 2, 2014 at 10:02 AM Michael Mueller <abaci.mjm_at_gmail.com>
wrote:
> On Thu, Oct 2, 2014 at 3:02 AM, Dan Fandrich <dan_at_coneharvesters.com>
> wrote:
>
> >That also means that if the library is not in a
> > standard location at run-time you must separately ensure that the
> > dynamic
> > linker is able to find it (e.g. by mentioning it in
> > /etc/ld.so.conf).
>
> ...if you have root privileges...which I never have on production
> systems. LD_LIBRARY_PATH is what we use. That's the direction I'm
> headed today. The -R and -rpath options (works on Linux; not so much
> for me on SunOS 5.10) apparently locks libcurl into using only the
> path specified. I've been informed that our installs cannot rely on
> being in the same location on all systems, so -R is no longer an
> option for me.
>
> I'm going back to using PKG_CONFIG_PATH since I no longer want to set
> -R.
>
> Can OP post ./configure command line being used?

Just a head up, if you can not rely on your installs being in the same
PATH
then don't expect much in terms of stability with the use of the dreaded
and terrible LD_LIBRARY_PATH. If a given binary does not supply a
RUNPATH
for the NEEDED libs in the ELF header then your runtime linker will just
blindly follow that LD_LIBRARY_PATH thing and you have to hope you have
consistent libs in place. Any user with a cluse could put in a lib-file
with the right matching SONAME into their own $HOME/lib if they wanted
and all sorts of really bad things can happen.
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2014-10-03