[...] can someone please *exactly* explain [...] why [a symbol] would need to be versioned ?
[...] In order to solve a problem, you need first to exactly identify the problem.
email sent. in summary, consider memcpy()
https://man7.org/linux/man-pages/man3/memcpy.3.html Failure to observe the requirement that the memory areas do not
overlap has been the source of significant bugs. (POSIX and the
C standards are explicit that employing memcpy() with overlapping
areas produces undefined behavior.) Most notably, in glibc 2.13
a performance optimization of memcpy() on some platforms
(including x86-64) included changing the order in which bytes
were copied from src to dest.
This change revealed breakages in a number of applications that
performed copying with overlapping areas. Under the previous
implementation, the order in which the bytes were copied had
fortuitously hidden the bug, which was revealed when the copying
order was reversed. In glibc 2.14, a versioned symbol was added
so that old binaries (i.e., those linked against glibc versions
earlier than 2.14) employed a memcpy() implementation that safely
handles the overlapping buffers case (by providing an "older"
memcpy() implementation that was aliased to memmove(3)).with FPC, if
memcpy() is not explicitly versioned in the Pascal source, then the version of the
memcpy() symbol present in the resulting ELF binary will vary depending on the installed glibc at compile-time. this version decision is made by the compile-time linker: either
memcpy@GLIBC_2.2.5 or
memcpy@GLIBC_2.14. the linker always selects for the 'newest' version found at compile-time if not directed otherwise.
the resulting binary
will behave differently depending on the version of
memcpy() selected by the compile-time linker.
the same principal applies to
__libc_start_main. changes are 'in the air', and there is suggestion that at some not-too-distant future time the
parameters to
__libc_start_main may be changed. this will result in a new versioned
__libc_start_main being introduced, which FPC will link against unless directed otherwise. this will result in an ELF binary that crashes if created on a machine that has this new version of
__libc_start_main available. simple as that.
the same principal as applies to
__libc_start_main then applies to
dlopen() or any other glibc symbol.
to avoid this Florian Weimer has confirmed that FPC should link against the BASE version of the glibc symbols. essentially, this is the @GLIBC_2.2.5 versions - getting the right version numbers involves some one-off processing of the output from
readelf -a libc.so.6.
cheers,
rob :-)