# Library Path addition not appending but replacing! **URL:** \ **Category:** SLES Configure-Administer\ **Created:** [May 23, 2012, 6:54pm UTC](https://forums.suse.com/t/library-path-addition-not-appending-but-replacing/22662 "2012-05-23T18:54:47Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![lpphiggp](https://avatars.discourse-cdn.com/v4/letter/l/54ee81/32.png) [@lpphiggp](https://forums.suse.com/u/lpphiggp)\ **Post date:** [May 23, 2012, 6:54pm UTC](https://forums.suse.com/t/library-path-addition-not-appending-but-replacing/22662/1 "2012-05-23T18:54:47Z")
Server info: :/etc # uname -a Linux srvrname 2.6.16.60-0.91.1-xen #1 SMP Tue Oct 18 21:40:25 UTC 2011 i686 i686 i386 GNU/Linux :/etc # cat SuSE-release SUSE Linux Enterprise Server 10 (i586) VERSION = 10 PATCHLEVEL = 4 :/etc # cat novell-release Novell Open Enterprise Server 2.0.3 (i586) VERSION = 2.0.3 PATCHLEVEL = 3 BUILD We’re using Syncsort Backup Express 3.21, but the client has a bug where, when trying to run it’s “detect” command, it won’t run because it’s own libraries are not in the path. The official fix is to issue this two commands: LD\_LIBRARY\_PATH=${LD\_LIBRARY\_PATH}:/opt/backupexpress/lib export LD\_LIBRARY\_PATH (This doesn’t survive a reboot, but I also found I could acheive the same result by simply appending “/opt/backupexpress/lib/” to the end of the /etc/ld.so.conf file and running ldconfig, which does survive a reboot. Again, on all other servers it’s not an issue) Sure enough, this command enables their detect command to run and report on attached SCSI devices. On most of our SLES/OES servers, setting the library path is not an issue, but on this one box, it apparently completely replaces all other library paths! Nothing in X11 works after that. Trying to run yast2 results in screen after screen of "couldn’t load or find library such and such errors. I have to issue a “unset /opt/backupexpress/lib” command to remove it from the path, then X works again. ---
**Author:** ![system](https://us1.discourse-cdn.com/flex022/uploads/suse/original/2X/5/5012ba89e3ffb5220dac47d5ea0ba032e2fe1cb6.png) [@system](https://forums.suse.com/u/system)\ **Post date:** [May 23, 2012, 11:07pm UTC](https://forums.suse.com/t/library-path-addition-not-appending-but-replacing/22662/2 "2012-05-23T23:07:10Z")
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Before going into this let me point out a few things that MAY make a difference. First, a variable is not global in scope. From the time it is set it applies only to the single environment in which it was set, and not even to child environments (sub-shells, etc.) unless exported (which you are doing). As a result when you write something like setting this messes up all kinds of things like X and every other application, it makes me think you’ve set this path somewhere that affects all subsequent programs (usually not a good idea) instead of in a single startup script where it can apply to the needed application (like Backup Express). Normally additions to variables like LD\_LIBRARY\_PATH or LD\_PRELOAD are set in the script which actually calls the binaries requiring the new libraries; not always, of course, but in cases where the new libraries are not system-specific, this is how it should work. Adding more libraries to somewhere that causes every application in the world to see this new set of libraries wastes time at best (one more place to check for stuff) and causes problems like you are seeing in more severe cases. Next, how do you know it is replacing? I am guessing that it is not replacing anything, but that LD\_LIBRARY\_PATH is not set at the time that you are “appending” to it (normally this variable is not needed for things since the system has its own location for global things). Appending to something that is not set at all means your LD\_LIBRARY\_PATH will end up looking like ‘:/opt/backupexpress/lib/’ and then have more, potentially, after that. This is another reason that these types of variable declarations/instantiations should happen in the startup script of the application which requires these types of modifications to work. Anytime you set something explicitly like this, though, any application that is C-based will look at the variable before checking the system’s collection of libraries and try to load what it finds, and any conflicting symbols will cause what you are seeing. In summary: do not set this globally unless it applies globally (this definitely does not) and you know it should be applied globally. Feel free to verify the value of LD\_LIBRARY\_PATH before you are setting it with something like an echo to a file, but I’d be willing to bet this is all a configuration issue. I’m a little surprised that Backup Express does not ship with a script that correctly sets the LD\_LIBRARY\_PATH variable for its own purposes like every other application does. Good luck. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - [http://enigmail.mozdev.org/](http://enigmail.mozdev.org/) iQIcBAEBAgAGBQJPvUNuAAoJEF+XTK08PnB57SwQAMVF4y1jDYmxsef/uzYWaXb4 g/rZRbhaCFYTuCxLUJqwLu/js/e3jS6G+CUHY1ZGGdrQTMIFRJK8HsPxF1a4bZGs y3zC9UbECwrklRjwJb1FVQm7jTPY/CrwcSWvW9YjZdGnW2VZHfLTpYFNJupUpxTm KTVLywlkAZn197R6nCWL/+vEGZPhx+xpMzWQ2rOu0tqkSUeHPApeSpldP0sVU2ga qO/bOIuZQ/uxEC7nGYRYJec14lsCpHmk5YzlhTZxHVRKszbUF7nD0UlJjFNBNDEZ LC5ZaAFQS8+aYi9Ts8fDVndCh+Mh6+gr9nGv5guPfjSY6ywJhphm2Bmo6xJks7zK qwt4u+iC7NkF1iiM26tu9zVdbmGVNMDRZNwpv6s86TcjiTTDmWbg5xZ9Ifo3l+rp xGfRuzbGUl3rxWELlX3DWFhSpO+pmI7e1jJ7u8ywRZ410t+ErDIExiZ2CfYqJkE1 Wo7z7MjaT2tOEuBe5BiYAvnxDkZNXtRTw1L23g/nXtuZsNq5/U4skTZGpV5R3eeO pav0N8gLg4QznNSywbfDzlk6jYdGMwGLsVrFUvIKiLRMHJ2vvCNwxLvpICzsmLmQ fFc57lY1+xYOz3A8e6rGC1JtsAsRNuL2UKKd9aONPEJB5AUPW1K+zl+G8xnHrD9e +Jg7RsZq6wJ/N/gphNGV =/qnW -----END PGP SIGNATURE----- ---
**Author:** ![ashbyj](https://avatars.discourse-cdn.com/v4/letter/a/258eb7/32.png) [@ashbyj](https://forums.suse.com/u/ashbyj)\ **Post date:** [May 24, 2012, 8:38pm UTC](https://forums.suse.com/t/library-path-addition-not-appending-but-replacing/22662/3 "2012-05-24T20:38:18Z")
To make this lib path “stick”, you should create /etc/ld.so.conf.d/backex.conf with the any lib paths for Backup Express. Looks like you only have one: ```auto /opt/backupexpress/lib ``` Then run the command ldconfig -v. Linux uses /etc/ld.so.conf, or more precisely ld.so.cache which gets updated from the ldconfig command, to locate libraries. Anything in /etc/ld.so.conf.d/ is included in the main ld.so.conf file as you can see. The LD\_LIBRARY\_PATH environment var is also used to specify library paths, but as the other poster mentioned, thats only set for your current shell session. ---
**Author:** ![lpphiggp](https://avatars.discourse-cdn.com/v4/letter/l/54ee81/32.png) [@lpphiggp](https://forums.suse.com/u/lpphiggp)\ **Post date:** [May 25, 2012, 8:44pm UTC](https://forums.suse.com/t/library-path-addition-not-appending-but-replacing/22662/4 "2012-05-25T20:44:37Z")
Just want to note, I ran the export command because that is expressly what Backup Express says to do in their TID, regarding this issue. (They acknowledge this) However, this workaround this doesn’t seem to affect any other servers in the same, but just this one (which I didn’t set up) I know that this env setting on this server caused issues because once set, I couldn’t run anything in X on it, I got tons of library errors. If I then ran an “unset LD\_LIBRARY\_PATH” command, everything returned back to normal. I also checked against other servers that I have never done this with, and no LD\_LIBRARY\_PATH appeared in their env, so that appears to be the default. In any case, I think I found my own workaround. This detect command failed due to only a single library file it couldn’t find (libcmapi.so); I did a find on the entire file system and no other instance of that lib file existed but the one, so I put a softlink to it inside another library directory already on the path (/usr/lib). Now I can run the command, and, X isn’t borked either. ---
**Author:** ![lpphiggp](https://avatars.discourse-cdn.com/v4/letter/l/54ee81/32.png) [@lpphiggp](https://forums.suse.com/u/lpphiggp)\ **Post date:** [May 25, 2012, 8:47pm UTC](https://forums.suse.com/t/library-path-addition-not-appending-but-replacing/22662/5 "2012-05-25T20:47:37Z")
Thanks ashbyj, I’ll remember this tidbit for future reference, but I think I found another workaround for this issue that seems to be working. (see above) AFAIK, it’s only this “detect” command of theirs that doesn’t work right, so I should be okay.