No, not in a flattering way. I've been doing some work with Solaris and I finally got my programming environment set up the way I want it.

g++ is installed, everything is ready to go, but wait, I need to set the LD_LIBRARY_PATH. Ok, modified etc/profile, time to reboot and have some fun.
Oh no. No fun for me.

After logging into JD:

Quote

There was an error starting the GNOME Settings Daemon
Nautilus can't be used now, due to an unexpected error
There was a problem registering the panel with the bonobo activation server

And a few other dialog boxes informing me of their utter incompetence.

Uh, what? I modified a config file and that's it. Now my computing has come to a screeching halt for no apparent reason. To top it off, CDE works fine (I can't stand it).

Initial findings pointed to left over crap in the usr/tmp directory, but that wasn't helpful, nor was inspecting the logs in var/dt/Xerrors. All of my Google-fu has been null and void up to this point, so if you've run into this before or know a guy who knows a guy, feel free to shoot me a message.

Update: Looks like the best alternative is to use -R when linking and just throw that into a makefile.

8 Comments On This Entry

WHy are you modifying /etc/profile. There exists in your home directory a .profile that you can modify that will only make changes for you. Also, if the change you made to /etc/profile was too add a library search path, I would add the path to /etc/ld.so.config. That file exists for the sole purpose of adding library paths. After you edit that file you need to run ldconfig to update the environment. No rebooting necessary.

Still doesn't explain why those two lines would destroy one window system login and leave the other alone.

Depends on what was in LD_LIBRARY_PATH. You could very well have been overriding a set of libraries used by one desktop and not the other. Which is why setting LD_LIBRARY_PATH without knowing what you're doing is a bad idea.

Adding a library path involves editing /etc/ld.so.conf or adding a file with the library location to the directory /etc/ld.so.conf.d/. After you've done that run ldconfig and it will update your library paths. You don't even have to reboot.

That variable wasn't set prior to me giving it a value. I ensured I wouldn't inadvertently overwrite things already in place.

That's the thing - it doesn't matter whether it was already set or not. If you put the wrong value in LD_LIBRARY_PATH, you can still break things.

Here's a concrete example for you. Run the following commands:

ldd /bin/ls
mkdir ~/lib
touch ~/lib/libc.so.6 #Assuming that libc.so.6 is the version in the output of ldd
LD_LIBRARY_PATH=$HOME/lib ls

This code sets LD_LIBRARY_PATH to a directory that contains a bad (in this case empty) copy of libc and then tries to execute the ls command. Notice the error message - the linker is dutifully trying to load the library from LD_LIBRARY_PATH and then barfs all over itself when it can't.

Now imagine what happens if you have two versions of the same library installed on your system and a number of programs that will work with only one of those versions. If you set LD_LIBRARY_PATH to point at the wrong one, all those programs are going to fail. This is why messing with the library path is generally considered a bad idea, especially when it's set globally.