Linking with a particular shared library by full path overridingLD_LIBRARY_PATH

[Visa Inquirer]

I need my program to always link to a particular shared library, not
the one in LD_LIBRARY_PATH.

Is there a way to specify shared library by full path when linking so
that when running LD_LIBRARY_PATH is ignored?

 

[Walter Roberson]

I need my program to always link to a particular shared library, not
the one in LD_LIBRARY_PATH.

Is there a way to specify shared library by full path when linking so
that when running LD_LIBRARY_PATH is ignored?

There are often ways to link shared libraries "statically" -- to
bring the entire shared library in to an executable as if it had
originally been a non-shared library. If you did that, then any
dynamic library search path would not matter, as the library would
not be listed as needing to be dynamically found.

Beyond that... well, it would probably be better for you to ask in
a forum that has an idea of what LD_LIBRARY_PATH is. LD_LIBRARY_PATH
is not part of standard C, and is very unlikely to become part of
standard C (the name conflicts with the namespace reserved for
user programs). Perhaps you want a general unix programming group,
or perhaps you want a programming group specific to whatever OS you
are using. I could give you the answer for the system I'm using
right now, but I have no idea whether the solution would work for
whatever OS you are using (probably not, though.)

 

[Ian Collins]

I need my program to always link to a particular shared library, not
the one in LD_LIBRARY_PATH.

LD_LIBRARY_PATH is both evil and off topic. Try comp.unix.programmer.

 

[Antoninus Twink]

I need my program to always link to a particular shared library, not
the one in LD_LIBRARY_PATH.

Is there a way to specify shared library by full path when linking so
that when running LD_LIBRARY_PATH is ignored?

You can set the program's rpath: this will hard code a dynamic library
search path into your binary, and on most systems this will override
LD_LIBRARY_PATH.

With gcc, you can provide
-rpath dir
as an option when linking, and this will add dir to the executable's
run-time link path.

You should be aware that setting the rpath can cause all sorts of
problems if your program is installed by people who want to install
their libraries somewhere other than your preferred hard-coded search
path.

 

[Walter Roberson]

The name conflicts in *WHAT* namespace? I don't see any place
in the C standard where environment variable names are reserved for
user programs.

The original poster made no indication that LD_LIBRARY_PATH was
an environment variable, only that it was a name whose value
the poster wished to be ignored.

 

[Walter Roberson]

You can set the program's rpath: this will hard code a dynamic library
search path into your binary, and on most systems this will override
LD_LIBRARY_PATH.

Most systems? I dunno about that. Certainly not on the system I'm
using now -- here the -rpath ld option *adds* the given directory
to the search path, but does not override LD_LIBRARY_PATH (or the
system variations therein such as LD_LIBRARY64_PATH). On the system
I'm using, you have to link with -no_library_replace to prevent
the path specified in the binary from being overridden.