Bug#223384: libc6: Global constructors from shared objects are sometimes run in the wrong order

[Avery Pennarun <apenwarr@nit.ca>]

Package: libc6
Version: 2.3.2.ds1-10
Severity: normal

Here's a greatly simplified test case of a problem I had today.

If you extract the attached tarball and type the following,

	cd ldtest
	export LD_LIBRARY_PATH=$PWD
	make
	./main
	
The output is as follows:

	creating libwvstreams.so
	creating libpthread.so
	creating libdb-4.0.so
	creating libwvutils.so
	starting

The output should be like this instead:

	creating libwvutils.so
	creating libwvstreams.so
	creating libpthread.so
	creating libdb-4.0.so
	starting

Or, at any rate, libwvutils.so should somehow be initialized before
libwvstreams.so, since libwvstreams.so depends on that library, and not the
other way around.  As you can see in the Makefile, there are no dependency
loops, so there's no reason to initialize the libraries in the wrong order.

Removing libdb entirely, or linking libpthread.so to main *before*
libwvstreams.so instead of after, eliminates the problem.

Note that, in my test case, all the libraries are actually empty except for
the global object whose constructor prints the above messages; there are no
symbol inter-references between the libraries.

This test case performs identically with glibc 2.3.2 in the current Red
Hat, so it's not a debian-specific bug.

Thanks,

Avery


-- System Information
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux insight 2.4.19 #1 mer sep 4 10:52:04 EDT 2002 i686
Locale: LANG=fr_CA, LC_CTYPE=fr_CA

Versions of packages libc6 depends on:
ii  libdb1-compat                 2.1.3-7    The Berkeley database routines [gl

Attachment: ldtest.tar.gz
Description: Binary data