This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
LSB 3.0 compliance of libstdc++.so.6 independent of allocator?
- From: Matthias Klose <doko at cs dot tu-berlin dot de>
- To: lsb-discuss at freestandards dot org
- Cc: libstdc++ at gcc dot gnu dot org, debian-gcc at lists dot debian dot org
- Date: Fri, 11 Nov 2005 12:06:43 +0100
- Subject: LSB 3.0 compliance of libstdc++.so.6 independent of allocator?
Running the C++ tests of the lsb testsuite results in identical
results for a libstdc++ configured with the standard allocator and one
configured with the mt allocator. Building libraries like arts with
these different configurations results in incompatible libraries (the
ones using the libstdc++ with the default allocator missing various
mt_alloc symbols). I.e. on the Debian unstable distribution, in total
about 450 packages define mt_alloc related symbols or reference them
(about 1700 packages depending on libstdc++ in total).
- Is this behaviour intended?
- I cannot find a comment, how a particular implementation
(i.e. libstdc++ from the GCC source) has to be configured to allow
LSB compliance. AFAIK every Linux distribution configures GCC using
--enable-__cxa_atexit although it's not the upstream default. At
least two distributions (Fedora until July 2005 and Debian)
configure libstdc++ using --enable-libstdcxx-allocator=mt.
Matthias