9

What is the best place to set up application specific LD_LIBRARY_PATH variable on Solaris? How does

LD_LIBRARY_PATH

variable work?

We currently set it up in .kshrc, but different applications need different versions of messaging framework, but these applications run under the same use and hence they would need different LD_LIBRARY_PATH, so in your opinion what is the best place to set this variable?

Basically I am trying to figure out how to make this variable path part of the application instead of user environment specific.

ceving
  • 21,900
  • 13
  • 104
  • 178
Ville M
  • 2,009
  • 7
  • 30
  • 45

7 Answers7

14

Usually I would just have a shell script that starts the application. In the shell script I would set LD_LIBRARY_PATH to whatever I need it to be for that app, then have the script start that app. Doing it that way should cause the path to be set only for that application.

Eric Petroelje
  • 59,820
  • 9
  • 127
  • 177
  • Thanks, thats along the lines I was thinking. However would it make sense to put that variable in external app_profile file and then source that file in the script? Or do you see any problems with that? I am thinking since multiple apps do need the same path it might make sense to externalize it? – Ville M Mar 02 '09 at 22:24
  • LD_LIBRARY_PATH (or LD_LIBRARY_PATH_32 and LD_LIBRARY_PATH_64) needs to be set before the executable is launched - because ld.so.1 reads it before you get to main() and doesn't reread it afterwards. – Jonathan Leffler Mar 02 '09 at 22:29
  • @Ville - I think that would work, but you'll want to try it out first to be sure – Eric Petroelje Mar 03 '09 at 00:57
  • @Jonathan - This would be before the executable is launched. You are setting the path in the script, then the script is launching the executable. – Eric Petroelje Mar 03 '09 at 00:58
6

You can find a formal description of LD_LIBRARY_PATH on the man page for "ld.so.1", ie run "man ld.so.1". It also describes some other variables that are honored by the runtime linker.

In addition to LD_LIBRARY_PATH, executables and shared libraries can also have a built-in search path for libraries. If you are running an application that you have linked yourself, you can use ld's -R option to set the built in path (both Sun CC and gcc have options to do the same thing). This may allow you to avoid using LD_LIBRARY_PATH in the first place.

Kenster
  • 23,465
  • 21
  • 80
  • 106
2

Vladr, alanc is correct.

It's not recommended to set LD_LIBRARY_PATH on Solaris. At all.

If you need to bake a specific runpath into your library or executable, then you should use the -R flag to the linker. If building with gcc, then use -Wl,Rpath (I think).

If you need to do this for a post-build step (eg, because you're lacking source to recompile), then elfedit(1) will help you a lot. It's documented in the manpage, and also in the Linker+Libraries Guide at http://docs.oracle.com/cd/E26502_01/html/E26507/index.html

James McPherson
  • 2,476
  • 1
  • 12
  • 16
  • For compatibility reasons, GCC on Solaris also understands `-R`. You can still use `-Wl,-Rsomedir` because it is then portable to Linux. Or use `-Wl,-rpath,somedir` which is also understood e.g. by runtime linker on Solaris and Linux. – maxschlepzig Jul 26 '16 at 20:38
1

The crle response is most correct. On Solaris, LD_LIBRARY_PATH shouldn't be used. Use crle instead. To view the current paths, just run "crle" by itself. To update the list, use crle -u -l /path/to/your/lib/directory. The -u is needed to write changes to the system configuration, otherwise the change will be temporary. See the man page for more options.

sra
  • 23,820
  • 7
  • 55
  • 89
Dan Ramaley
  • 31
  • 1
  • 2
    As noted in the comments on the previous crle answer, it's not the best solution, since it affects *all* programs, not just the broken ones that need a different path than they were built with. A shell script wrapper to set LD_LIBRARY_PATH just for those applications is much safer and saner than risking changes to all programs, and is the only way to deal with different applications needing incompatible paths. – alanc Jun 09 '10 at 16:20
  • 2
    @alanc, incorrect; you can use `crle -c` to define per-application environments, a la Windows manifests (see Example 6 at http://docs.oracle.com/cd/E19082-01/819-2239/crle-1/index.html). – vladr May 20 '13 at 16:34
0

You can check your .profile or .profile.user file.There will be be a commented entry for it .It's not recommended to be used since it's broken.You should build the binaries by passing values to flags rather than using the variable.

Iceman
  • 365
  • 1
  • 3
  • 13
0

Just found a case that global LD_LIBRARY_PATH doesn't take effect, I had to wrap a script and set LD_LIBRARY_PATH before the app. crle is a good global solution if you installed a lot of libs under /opt/csw/lib, via pkgutil from blastwave.

gengmao
  • 113
  • 1
  • 6
-1

You can use the crle command:

crle -l /path/to/your/lib/file

Sedawk
  • 21
  • 1
    crle suffers from the same problem as setting it in a global environment file - it affects all applications, so doesn't help when different applications need different versions of the libraries. – alanc Jan 04 '10 at 17:20
  • 1
    @alanc is *wrong*. `crle -c` will allow you to affect specific applications (see Example 6 at http://docs.oracle.com/cd/E19082-01/819-2239/crle-1/index.html) – vladr May 20 '13 at 16:35
  • 1
    I was referring to the way crle is used in the answer. I've never seen the use of crle you reference in the man page before, and it's not the way this answer says to use it. – alanc Feb 09 '14 at 21:59