Re: LSB patch to gcc 3.3 tree

["Gabriel Dos Reis" <gdr at acm dot org>]

You Wrote Michael Matz
> Hi,
>
> On Tue, 29 Jun 2004, Gabriel Dos Reis wrote:
>
>> From the gcc-3_4-branch, I see that libstdc++-v3/config/linker-map.gnu
>> exports a huge number of symbols for GLIBCXX_3.4.
>> [... what symbols are possible to export in 3.3 ...]
>>
>> ---> LSB people: could tell me whether, exporting those symbols
>> resolve the issues for you?  There is no way to go beyond as
>> it introduces an API incompatibility with GCC-3.4.x -- which seems
>> to be already working for you.
>
> I'm no LSB guy, but I thought it good to mention that the LSB testsuite
> would then miss the below symbols (i.e. on 3.3 with the below patch to
> export only the mentioned symbols).  I don't know wether this would be
> okay for LSB or not:

Hi Matt,  thanks for producing the patch.  Given feedback from
Benjamin and the fact that we cannot export more than GCC-3.4.x
does, I propose you you commit this in a very fours (give a chance
for LSB people to react.)

>
> _ZN10__cxxabiv111__terminateEPFvvE
> _ZN10__cxxabiv112__unexpectedEPFvvE
> _ZN9__gnu_cxx13stdio_filebufIcSt11char_traitsIcEE2fdEv
> _ZN9__gnu_cxx13stdio_filebufIcSt11char_traitsIcEED0Ev
> _ZN9__gnu_cxx13stdio_filebufIcSt11char_traitsIcEED1Ev
> _ZN9__gnu_cxx13stdio_filebufIcSt11char_traitsIcEED2Ev
> _ZN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEE2fdEv
> _ZN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEED0Ev
> _ZN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEED1Ev
> _ZN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEED2Ev
> _ZNSt21__ctype_abstract_baseIcED0Ev
> _ZNSt21__ctype_abstract_baseIcED1Ev
> _ZNSt21__ctype_abstract_baseIwED0Ev
> _ZNSt21__ctype_abstract_baseIwED1Ev
>
> which are demangled this:
>
> __cxxabiv1::__terminate(void (*)())
> __cxxabiv1::__unexpected(void (*)())
> __gnu_cxx::stdio_filebuf<char, std::char_traits<char> >::fd()
> __gnu_cxx::stdio_filebuf<char, std::char_traits<char> >::~stdio_filebuf()
> __gnu_cxx::stdio_filebuf<char, std::char_traits<char> >::~stdio_filebuf()
> __gnu_cxx::stdio_filebuf<char, std::char_traits<char> >::~stdio_filebuf()
> __gnu_cxx::stdio_filebuf<wchar_t, std::char_traits<wchar_t> >::fd()
> __gnu_cxx::stdio_filebuf<wchar_t, std::char_traits<wchar_t>
> >::~stdio_filebuf()
> __gnu_cxx::stdio_filebuf<wchar_t, std::char_traits<wchar_t>
> >::~stdio_filebuf()
> __gnu_cxx::stdio_filebuf<wchar_t, std::char_traits<wchar_t>
> >::~stdio_filebuf()
> std::__ctype_abstract_base<char>::~__ctype_abstract_base()
> std::__ctype_abstract_base<char>::~__ctype_abstract_base()
> std::__ctype_abstract_base<wchar_t>::~__ctype_abstract_base()
> std::__ctype_abstract_base<wchar_t>::~__ctype_abstract_base()
>
> So, are stdio_filebuf::fd() and the stdio_filebuf dtors really not usefull
> to export?

stdio_filebuf::df is an inline function in both GCC-3.3.x and
GCC-3.4.x.  Why would it need an export?  That function would
get emitted as weak (assuming ELF) in every translation unit
that uses it, assuming it never gets actually inlined.
The constructors and destructor are template functions and
get emitted in every translation unit (GNU linkonce section)
that uses them.

>  What about __terminate and __unexpected?  I guess it's not
> normal code which would call them, but perhaps there would be legitimate
> uses (I really don't know, that's why I ask).

Those are not exported in GCC-3.4.x.  GCC-3.3.x can't export them.

Thanks for your patience

>
>
> Ciao,
> Michael.
> --
>
> --- linker-map.gnu.33	2004-05-26 15:11:08.000000000 +0200
> +++ linker-map.gnu	2004-06-29 09:56:16.000000000 +0200
> @@ -399,6 +399,12 @@ GLIBCPP_3.2.4 {
>
>    _ZNSt9basic_iosI[cw]St11char_traitsI[cw]EE11_M_setstateESt12_Ios_Iostate;
>
> +  # For LSB 2.0
> +  # std::__ctype_abstract_base*
> +  #_ZNSt21__ctype_abstract_base*;
> +  # std::__codecvt_abstract_base*
> +  _ZNSt23__codecvt_abstract_base*;
> +
>  } GLIBCPP_3.2.3;
>
>  # Symbols in the support library (libsupc++) have their own tag.
> @@ -468,3 +474,32 @@ CXXABI_1.2.1 {
>      __cxa_guard_abort;
>
>  } CXXABI_1.2;
> +
> +CXXABI_1.2.2 {
> +    # _ZN10__cxxabiv1*;
> +    # *_type_info classes, ctor and dtor
> +    _ZN10__cxxabiv117__array_type_info*;
> +    _ZN10__cxxabiv117__class_type_info*;
> +    _ZN10__cxxabiv116__enum_type_info*;
> +    _ZN10__cxxabiv120__function_type_info*;
> +    _ZN10__cxxabiv123__fundamental_type_info*;
> +    _ZN10__cxxabiv117__pbase_type_info*;
> +    _ZN10__cxxabiv129__pointer_to_member_type_info*;
> +    _ZN10__cxxabiv119__pointer_type_info*;
> +    _ZN10__cxxabiv120__si_class_type_info*;
> +    _ZN10__cxxabiv121__vmi_class_type_info*;
> +
> +    #_ZNK10__cxxabiv1*;
> +    # *_type_info classes, member functions
> +    _ZNK10__cxxabiv117__class_type_info*;
> +    _ZNK10__cxxabiv120__function_type_info*;
> +    _ZNK10__cxxabiv117__pbase_type_info*;
> +    _ZNK10__cxxabiv129__pointer_to_member_type_info*;
> +    _ZNK10__cxxabiv119__pointer_type_info*;
> +    _ZNK10__cxxabiv120__si_class_type_info*;
> +    _ZNK10__cxxabiv121__vmi_class_type_info*;
> +
> +    #_ZN9__gnu_cxx*;
> +    # __gnu_cxx::_verbose_terminate_handler()
> +    _ZN9__gnu_cxx27__verbose_terminate_handlerEv;
> +} CXXABI_1.2.1;
>