Old version

Current versions of glibc failed to install on Centos 5.0 saying as, ld and gcc where too old.


Testing Testing glibc-2.30 fails

With tcsh cp: cannot stat /tmp/glibc-2.30/glibc-2.30/glibc-build/lib/ No such file or directory is not in the directory where it is expected. hints that this can be fixed with symbolic link.

Possible work around

Assuming your build directory is /tmp/glibc-2.30/glibc-2.30/glibc-build) (adjust directores as needed):
mkdir /tmp/glibc-2.30/glibc-2.30/glibc-build/lib/
cd    /tmp/glibc-2.30/glibc-2.30/glibc-build/lib/
ln -s ../glibc-build/elf/ .
Then make check in the build directory (e.g. glibc-build).
On a 3.6Ghz CPU make check takes in the region of half an hour or more.

ps: you will need a recent version of the GNU gcc compiler for glibc-2.30.


Testing Testing glibc-2.7 fails

With tcsh Testing ASCIIcommon_objpfx=/device/dir: Command not found.

Appears to be a known (and fixed) problem with glib's test suite (see Debian Bug report #517077 handling of SHELL environment variable). (Claimed to be fixed in glibc 2.9-4)

Possible work around

Set the environment variable SHELL to bash using setenv SHELL /bin/bash works. (It is not sufficient to simply remove SHELL with: unsetenv SHELL).

Other potential fixes

make[2]: *** [/tmp/z2/dlfcn/bug-atexit3.out] Error 1

Apparently bug-atexit3 failing to find libstdc++ is a
known problem when glibc has been configured with a non-default directory is specified by --prefix

Work around

Edit dlfcn/Makefile and remove or comment out bug-atexit3. mentions other work arounds. must be installed for pthread_cancel to work
Didn't expect signal from child: got `Aborted'

Seem like above problem for non-default directory.

Work around

To skip tests that insist on using existing system shared libraries (rather than version of glibc we are installing) edit nptl/Makefile rt/Makefile nptl/sysdeps/pthread/Makefile debug/Makefile

Compiling glibc fails: make[2]: *** [elf/] Error 1 glibc-2.7/elf/dl-addr.c:158: multiple definition of `_dl_addr_inside_object'

Not clear. Probably me breaking something else.

Potential Future Versions

make fails with undefined reference to `newfunction' on shared .os libraries

newfunction is something I am to add via another independently compiled .c source file.

It appears this possibility is ruled out, because when gcc creates shared libraries it uses its -Wl switch to pass an instruction to the unix ld linker to check that there are no missing symbols.

Work around

Remove -Wl,-z,defs from the gcc -shared -static-libgcc command line.

W.B.Langdon Back
8 March 2014 (Last update 2 Jan 2020)