Revert "Detect ld.so and libc.so version inconsistency during startup"

This reverts commit 6f85dbf102ad7982409ba0fe96886caeb6389fef.

Once this change hits the release branches, it will require relinking
of all statically linked applications before static dlopen works
again, for the majority of updates on release branches: The NEWS file
is regularly updated with bug references, so the __libc_early_init
suffix changes, and static dlopen cannot find the function anymore.

While this ABI check is still technically correct (we do require
rebuilding & relinking after glibc updates to keep static dlopen
working), it is too drastic for stable release branches.

Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>

1 files changed, 0 insertions, 9 deletions

diff --git a/manual/install.texi b/manual/install.texi
index 6d43599a47..c775005581 100644
--- a/manual/install.texi
+++ b/manual/install.texi
@@ -144,15 +144,6 @@ dynamic linker diagnostics to run on CPUs which are not compatible with
 the rest of @theglibc{}, for example, due to compiler flags which target
 a later instruction set architecture (ISA).
 
-@item --with-extra-version-id=@var{string}
-Use @var{string} as part of the fingerprint that is used by the dynamic
-linker to detect an incompatible version of @file{libc.so}.  For
-example, @var{string} could be the full package version and release
-string used by a distribution build of @theglibc{}.  This way,
-concurrent process creation during a package update will fail with an
-error message, @emph{ld.so/libc.so mismatch detected (upgrade in
-progress?)}, rather than crashing mysteriously.
-
 @item --with-timeoutfactor=@var{NUM}
 Specify an integer @var{NUM} to scale the timeout of test programs.
 This factor can be changed at run time using @env{TIMEOUTFACTOR}