Linux vs Solaris - Compiling software

Background:

At work I'm used to working on Solaris 10. We have sysadmins who know what they're doing and can help out if required.

I've compiled things like apache, perl and mod_perl from source without any problems.

I've been given a redhat server to play with and am hitting problems. The sysadmins are out sick at the moment.

I keep hitting problems regarding LD_LIBRARY_PATH when building software. At the moment for test purposes I am compiling to my home directory, as I don't have root, or permissions to install anywhere else.

I plan on having an area under /opt for us to install into, like we do on Solaris, but I'll need out sysadmin a开发者_如何学Pythonround to create that for us.

My .bashrc had nothing for LD_LIBRARY_PATH so I've been appending things to that to get stuff built (e.g. ffmpeg from source). I've been reading about this and apparently this isn't the way to go, it's not reliable or something. I don't have access to ldconfig (permission denied).

Now the quetions:

What is the best way to build applications under linux so that they won't break? Creating entries under /etc/ld.so.conf.d/ ?

Can anyone give a brief overview of what LD_LIBRARY_PATH actually does?

From the ld.so(8) man page:

  LD_LIBRARY_PATH
          A colon-separated list of directories in which to search for ELF
          libraries at execution-time.  Similar to  the  PATH  environment
          variable.

But honestly, find an admin. Become one if need be. Oh, and build packages.

LD_LIBRARY_PATH makes it possible for individual users or individual processes to add locations to the search path on a fine-grained basis. /etc/ld.so.conf should be used for system wide library path setting, i.e. deploying your application. (Better yet you could package it as an rpm/deb and deploy it through your distributions usual package channels)

Typically a user might use LD_LIBRARY_PATH to force execution of their program to pick a different version of a library. Normally this is useful for favouring debugging or instrumented versions of libraries, but you can also use it to inject your own code into 3rd party code. (It is also possible use this for malicious purposes sometimes, if you can alter someone's bash profile to trick them into executing your code, without realising it).

Some applications also set LD_LIBRARY_PATH if they install "private" libraries in non-default locations, i.e. so they won't be used for normal dynamic linking but still exist. For scenarios like this though I'd be inclined to prefer dlopen() and friends.

Setting LD_LIBRARY_PATH is considered harmful because (amongst other reasons):

1. Your program is dynamically linked based on your LD_LIBRARY_PATH. This means that it could link against a particular version of a library, which happened to be in your LD_LIBRARY_PATH e.g. /home/user/lib/libtheora.so. This can cause lots of confusion if someone else tries to run it with without yourLD_LIBRARY_PATH and ends up linking against the default version e.g. in /usr/lib/libtheora.so.
2. It is used in preference to any default system link path. This means that if you end up having a dodgy libc on you LD_LIBRARY_PATH it could end up doing bad things like compromising your account.

As ignacio said, use packages wherever you can. This avoids library nightmares.