I have a situation (on Linux or Solaris, at least), in which I install versions of GCC in non-standard directories (specifically, directories not owned & operated by root). With such an installation, when a GCC link finds a definition of an external reference in a shared library that is part of the .../lib subdirectory used by this installation, it treats the shared library as if it were also installed in one of the standard locations known to the dynamic linker, and does NOT store the path to the directory in which that library is found. The result is that to run the linked executable, one must either
1. Add this non-standard directory to one's LD_LIBRARY_PATH, or 2. Remember to include the appropriate -W,l-R option or whatever in and every compilation. For C programs, this is seldom an issue, although it can be if one uses -shared-libgcc. It's more problematic with G++, where a simple Hello World program that uses iostream requires this special treatment. Of course, I could just install everything in a standard location, but I keep several versions of GCC around, so that is not the best solution. Besides which, as a DEFAULT behavior, this strikes me as odd---linking against a standard shared library that the compiler (in principle) KNOWS will likely be unavailable or incompatible at execution. Of course, it's easy to come up with cases where you really want to make sure that the runtime link is satisfied from some standard location, so the current behavior has to be supported, but isn't it a little odd as a default? Comments and instructions as to how to configure my local GCC builds to do what I want by default (which in this case means recording the path to the non-standard library in the executables) welcome. Thanks. Paul Hilfinger