On Saturday 09 September 2017 14:49:43 fredvs wrote:
> Re-hello.
> Huh, in previous mail, at end please read this:
> The last war would be "What is better: libdl.so.2 or ld-linux.so.2 ?
> Could it be possible to imagine a different dynlibs.pas ?
> Actual dynlibs.pas is using libdl.so.2.
> Could it be possible to use ld-linux.so.2 instead (with correspondent
> methods, of course) ?
I do not understand, ld-linux.so.2 uses tables and library names built in in 
binary by "ld" at compile time. libdl.so.2 (actually libc.so.6) uses library 
and function names provided as strings by the application at runtime. I 
assume internally dlopen()/dlsym() use functions from ld-linux.so.2.

> And for static linking that already uses ld-linux.so.2,
> if  if the "external" bug is fixed, a custom name/path of the library
> may be used and so have the advantage of a "dynlibs" way.
Static linking means combining *.o and *.a files by "ld" at compiletime and 
does not use libraries of the target system at runtime.
Please do not confuse "static" linking and "dynamic" or better named "shared" 
"shared/dynamic" linking comes in two flavors, either loading by ld-linux.so.2 
using link information stored in executable by "ld" at compiletime or by 
explicit calls of dlopen()/dlsym() in user code. Neither of them is 
named "static" linking.


Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
mseide-msegui-talk mailing list

Reply via email to