I`m making Rox-App "like" packages that can have libraries in them. It seems ldconfig is needed for lib recognition.
I don`t see why $LD_LIBRARY_PATH isn`t good enough by itself like $PATH is. Probably ldconfig updates a database.
It seems that this method would not speed up the linking / run process much, but I don`t have a clear picture of it.
# The Q...
When a lib. is new, ldconfig needs to be run. If that lib. is moved, does ldconfig need to be run again? It seems so...
Or will different copies of the same lib in different packages still be "registered" and work without running ldconfig.
Rox-Apps and their libs are not always available, but I don`t think this is a problem as the libs are only for that pkg.
.
When exactly does ldconfig need to be run?
ldconfig creates a cache file(/etc/ld.so.cache) of libs located in the standard dirs (/lib and /usr/lib) and any dirs specified in the file /etc/ld.so.conf.
LD_LIBRARY_PATH lets you specify additional locations to be searched. If something is found in the LD_LIBRARY_PATH then the search ends there -that is LD_LIBRARY_PATH takes precedence over the normal paths and those listed in ld.so.conf.
Any time that libs are added or moved (to the standard paths or those listed in ld.so.conf), then the cache should be updated.
LD_LIBRARY_PATH lets you specify additional locations to be searched. If something is found in the LD_LIBRARY_PATH then the search ends there -that is LD_LIBRARY_PATH takes precedence over the normal paths and those listed in ld.so.conf.
Any time that libs are added or moved (to the standard paths or those listed in ld.so.conf), then the cache should be updated.
ldconfig creates the links libWHATEVER.so.0 -> libWHATEVER.so.0.1.9 . It does not link libWHATEVER.so to libWHATEVER.so.0.1.9 . If you have libWHATEVER.so.0.1.7, libWHATEVER.so.0.1.8 and libWHATEVER.so.0.1.9 installed in one libdir ie /usr/lib it is very good in linking to the highest (latest) version number (*0.1.9 in this case) . If you rename libWHATEVER.so.0.1.9 to something like libWHATEVER-out.so.0.1.9-out because that lib is no good then ldconfig still mostly links libWHATEVER.so.0 -> libWHATEVER-out.so.0.1.9-out . I had to rename the lib like out-libWHATEVER.so.0.1.9 to cheat ldconfig .
«Give me GUI or Death» -- I give you [[Xx]term[inal]] [[Cc]on[s][ole]] .
Macpup user since 2010 on full installations.
People who want problems with Puppy boot frugal :P
Macpup user since 2010 on full installations.
People who want problems with Puppy boot frugal :P
Karl; Yeah, I`ve played with replacing libs. and saw the same naming results.
I don`t see any conflicting lib. problems as long as path presidence is set.
amigo; So if I understand you correctly... ldconfig only sets up the cache.
I know LD_LIB_PATH comes first, but you say ldconfig has nothing to do with it.
LD_LIB_PATH will work all on it`s own without running ldconfig as I stated above.
I`ve had mixed results with LD_LIB_PATH, so I wanted clarification.
# Thanks Karl and amigo, truly a pair of good friends! Terry B.
I don`t see any conflicting lib. problems as long as path presidence is set.
amigo; So if I understand you correctly... ldconfig only sets up the cache.
I know LD_LIB_PATH comes first, but you say ldconfig has nothing to do with it.
LD_LIB_PATH will work all on it`s own without running ldconfig as I stated above.
I`ve had mixed results with LD_LIB_PATH, so I wanted clarification.
# Thanks Karl and amigo, truly a pair of good friends! Terry B.
As Karl stated, ldconfig also creates symlinks to the libs when missing or outdated.
You need to understand how programs actually get executed. The shel does not run them and neither does the kernel. The kernel will start an ELF executable by using /lib/ld-linux.so.2 -the 'linker'.
ld-linux reads the ELF header (the first bytes of the program) where the symbols are kept for each and any libryries needed by the program. If LD_LIBRARY_PATH is set, then that location is the first to be searched. If still not found, then the libs are searched for in the standard dirs( /lib and then /usr/lib) and then in any additional locations specified in the ld.so.conf file. The cache which ldconfig gernerates prevents ld-linux from having to search for the libs -they are pre-listed in the cache. The cache must be updated when anything new gets installed in the standard dirs or the locations listed in ld.so.conf. This is why new libs are not found and used unless the cache is refreshed first.
So, the search order is:
LD_LIBRARY_PATH
/lib
/usr/lib
Locations specified in ld.so.conf
The linker will use the first matching lib it finds and not search further for that specific lib.
You need to understand how programs actually get executed. The shel does not run them and neither does the kernel. The kernel will start an ELF executable by using /lib/ld-linux.so.2 -the 'linker'.
ld-linux reads the ELF header (the first bytes of the program) where the symbols are kept for each and any libryries needed by the program. If LD_LIBRARY_PATH is set, then that location is the first to be searched. If still not found, then the libs are searched for in the standard dirs( /lib and then /usr/lib) and then in any additional locations specified in the ld.so.conf file. The cache which ldconfig gernerates prevents ld-linux from having to search for the libs -they are pre-listed in the cache. The cache must be updated when anything new gets installed in the standard dirs or the locations listed in ld.so.conf. This is why new libs are not found and used unless the cache is refreshed first.
So, the search order is:
LD_LIBRARY_PATH
/lib
/usr/lib
Locations specified in ld.so.conf
The linker will use the first matching lib it finds and not search further for that specific lib.
- technosaurus
- Posts: 4853
- Joined: Mon 19 May 2008, 01:24
- Location: Blue Springs, MO
- Contact:
when you are building a shared library you do the final link like:
gcc -shared *.o -Wl,-soname,libmylib.so.0 -o libmylib.so.0.2
so the output file will be libmylib.so.0.2 and it will contain a special symbol such that an objdump -x libmylib.so.0.2 will contain:
SONAME libmylib.so.0
but whenever you compile&link against it like:
gcc myapp.c -o myapp -lmylib
the compiler only looks for libmylib.so or libmylib.a in /lib /usr/lib (and wherever you specify with -L/path/) unless you explicitly specify a full path to the library itself
recall that the actual lib name is libmylib.so.0.2 and libmylib.so should be a symbolic link to that
the linker uses the embedded SONAME symbol to declare that it needs the library with that soname (SONAME libmylib.so.0) and stores a symbol in the binary such that an objdump -x myapp will contain:
NEEDED libmylib.so.0
When you run a program the loader only looks in $LD_LIBRARY_PATH for the NEEDED libmylib.so.0 that is embedded in the symbol table.
long story short:
.so is for the compiler
.so.X is for the loader
.so.X.x... is so you can have multiple versions installed
you never _need_ to run ldconfig, you _can_ manage the symlinks manually, but its pretty quick to run after you install any libraries and having an entry in /etc/ld.so.cache may speed up load times (though imperceptibly)
btw it is possible to just:
gcc -shared *.o -Wl,-soname,libmylib.so -o libmylib.so
(but then new versions overwrite old)
gcc -shared *.o -Wl,-soname,libmylib.so.0 -o libmylib.so.0.2
so the output file will be libmylib.so.0.2 and it will contain a special symbol such that an objdump -x libmylib.so.0.2 will contain:
SONAME libmylib.so.0
but whenever you compile&link against it like:
gcc myapp.c -o myapp -lmylib
the compiler only looks for libmylib.so or libmylib.a in /lib /usr/lib (and wherever you specify with -L/path/) unless you explicitly specify a full path to the library itself
recall that the actual lib name is libmylib.so.0.2 and libmylib.so should be a symbolic link to that
the linker uses the embedded SONAME symbol to declare that it needs the library with that soname (SONAME libmylib.so.0) and stores a symbol in the binary such that an objdump -x myapp will contain:
NEEDED libmylib.so.0
When you run a program the loader only looks in $LD_LIBRARY_PATH for the NEEDED libmylib.so.0 that is embedded in the symbol table.
long story short:
.so is for the compiler
.so.X is for the loader
.so.X.x... is so you can have multiple versions installed
you never _need_ to run ldconfig, you _can_ manage the symlinks manually, but its pretty quick to run after you install any libraries and having an entry in /etc/ld.so.cache may speed up load times (though imperceptibly)
btw it is possible to just:
gcc -shared *.o -Wl,-soname,libmylib.so -o libmylib.so
(but then new versions overwrite old)
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].