Re: LSB 3.0 compliance of libstdc++.so.6 independent of allocator?

[Benjamin Kosnik <bkoz at redhat dot com>]

> 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).

I suggest you ask FSG for clarification, since this is an LSB issue.

> - Is this behaviour intended?

This behavior is known. See:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21072

> - 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.

I am not in favor of linux distros switching the allocator. It should
remain in the default setting, as shipped with official FSF releases.
Distros that did this were and are mistaken, and Fedora at least will
not be doing this in the future.

I'm of the thought that --enable-__cxa_atexit is essential and
required, and that without it some of the libstdc++ tests (which are
then used by the FSG for the LSB test suite) will not pass. I am in
support of making this the default config for linux. There's been some
talk of that, but no action. Perhaps now is that time.

best,
benjamin