If you wish to know more about those parameters (NEEDED etc) and about versioning then you could perhaps also have a look here for more technical details.
a good read - but oh so complicated! it looks like
--allow-shlib-undefined passed to the linker
may achieve the same result as a fake
libdl.so file, has anyone tried this? i agree, it would be nice to find a solution that does not involve tinkering with the RTL source or creating fake libraries.
Fred vS suggests that simply creating the symlink is safe and that it should not break anything - what do you think?
[...] I think it can't harm but on the other side how does it reflect on functions that really requires a fix especially when code relies on certain behaviour.
that has always been one of my major concerns - and was pointed out by PascalDragon earlier on. however, as funlw65 alludes to, what happens if the old
@GLIBC_2.2.5 symbols and the functions that lie behind them are depreciated by the GLIBC developers at some future time? these symbols are, after all, already 20 years old.
if some versioned symbols
are depreciated, then strictly speaking i feel that
libc.so.6 should be bumped up to
libc.so.7, but we can not be certain this will happen in practice. Fred vS has emailed me with this concern. if the FPC RTL (and Lazarus LCL) made use of the C header files to define the prototypes of the library functions they use (such as
dlopen() etc) then one could simply rebuild the RTL and LCL. but (in the case of the FPC RTL at least) the C header files are
not used, instead the function prototypes hard-coded. and hard-coded in a selection of locations that it is not necessarily easy to locate - this is good reason in itself for ALL
externals to library functions being brought together into a
single .inc file. but that is way beyond the scope of my own experiments.
i would also suggest that research be carried out into having ONLY
__libc_start_main,
dlopen, and
dlsym accessed by
external. ALL other library calls should then be managed through
dlopen and
dlsym. if this is possible, then it substantially reduced the exposed surface, as well as allowing for the RTL et al to catch incompatibility errors and intelligently decide how to handle versioned symbols with multiple prototypes as required.
@WayneSherman: thank you for the pointers/links !
likewise, many thanks Wayne. we do need fresh eyes looking at these problems. it is a shame we do not have one or two of the GLIBC developers involved, as i am sure they could provide useful guidance! your checks indeed show how
libdl.so symlink has itself been purged from some distros.
cheers,
rob :-)
Recent
