This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: LSB patch to gcc 3.3 tree
- From: Benjamin Kosnik <bkoz at redhat dot com>
- To: gdr at acm dot org
- Cc: matz at suse dot de, dbb at beatties dot us, gcc-patches at gcc dot gnu dot org, mats dot d dot wichmann at intel dot com, anderson at freestandards dot org, dbb at freestandards dot org, libstdc++ at gcc dot gnu dot org
- Date: Tue, 29 Jun 2004 08:38:17 -0500
- Subject: Re: LSB patch to gcc 3.3 tree
- Organization: Red Hat / Chicago
- References: <20040628205604.GF14453@beatties.us><32889.::ffff:128.194.146.36.1088456910.squirrel@webmail.nerim.net><Pine.LNX.4.58.0406290051440.14966@wotan.suse.de><37195.::ffff:24.250.169.187.1088469697.squirrel@webmail.nerim.net><Pine.LNX.4.58.0406290957350.14966@wotan.suse.de><37281.::ffff:24.250.169.187.1088500480.squirrel@webmail.nerim.net>
>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.)
I agree.
>> __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.
Same here.
>> --- 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;
This should be in a new section, GLIBCPP_3.2.5
Please just use the 3.4. style instead of these blanket exports.
>> # 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;
.... like this part, which is fine.
-benjamin