[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: build configuration help
From: |
John Calcote |
Subject: |
Re: build configuration help |
Date: |
Thu, 03 Apr 2008 08:55:27 -0600 |
User-agent: |
Thunderbird 2.0.0.12 (Windows/20080213) |
Bob Rossi wrote:
If I put it in the lib directory on other platforms, on startup, how
will the binary know where to find the .so? That's why I was asking
about LD_LIBRARY_PATH, and creating a script....
Okay, let me ask a few questions to clarify your situation. First, is
this library being loaded by the linker at runtime, or is it dynamically
loaded by your application, using dlopen/dlsym/dlclose (Linux), or
LoadLibrary/GetProcAddress/FreeLibrary (Win32)?
On Unix systems the "library path" is configured in your application,
and in the system. Libraries are searched for (in general) in the system
linker cache, which by default contains (at least)
"/usr/local/lib:/usr/lib:/lib", as well as others in most cases. If your
library is being loaded by the system at app init time, then it should
have no trouble finding your library if it's installed in one of these
two places. Here's some text I copied (shamelessly) from the ld man page:
The linker uses the following search paths to locate required
shared libraries.
1. Any directories specified by -rpath-link options.
2. Any directories specified by -rpath options. The
difference between
-rpath and -rpath-link is that directories specified by
-rpath options are
included in the executable and used at runtime,
whereas the -rpath-link
option is only effective at link time. It is for the
native linker only.
3. On an ELF system, if the -rpath and "rpath-link"
options were not
used, search the contents of the environment variable
"LD_RUN_PATH".
It is for the native linker only.
4. On SunOS, if the -rpath option was not used, search any
directories
specified using -L options.
5. For a native linker, the contents of the environment variable
"LD_LIBRARY_PATH".
6. For a native ELF linker, the directories in "DT_RUNPATH" or
"DT_RPATH" of a shared library are searched for
shared libraries
needed by it. The "DT_RPATH" entries are ignored if
"DT_RUNPATH"
entries exist.
7. The default directories, normally /lib and /usr/lib.
8. For a native linker on an ELF system, if the file
/etc/ld.so.conf exists, the
list of directories found in that file.
If you're linking dynamically at runtime using the dlopen/dlsym/dlclose
functions, then you can use some of these mechnisms yourself to find
your library, plus, often an application will allow configuration in a
.conf file to allow the administrator to configure where the app should
look for libraries.
So you see, the search algorithms are similar on Unix and Windows
systems - they just look in different places. Windows treats libraries
like binaries, so expects to find them in the executable path, while
Unix treats them as separate first-class entities. They have their own
search paths, separate from binaries, plus about half a dozen other ways
to find libraries - some system-configured, and others hard-coded into
your app by the linker. But none of these methods look in the bin
directory for a library.
John
- build configuration help, Bob Rossi, 2008/04/03
- Re: build configuration help, John Calcote, 2008/04/03
- Re: build configuration help, Bob Rossi, 2008/04/03
- Re: build configuration help, NightStrike, 2008/04/03
- Re: build configuration help,
John Calcote <=
- Re: build configuration help, Bob Rossi, 2008/04/03
- Re: build configuration help, John Calcote, 2008/04/03
- Re: build configuration help, Bob Rossi, 2008/04/03
- Re: build configuration help, Andreas Schwab, 2008/04/03
- Re: build configuration help, John Calcote, 2008/04/03