Versioning problem with __register_frame

[Martin Schwidefsky]

>> On Wed, Jan 30, 2002 at 01:45:35PM +0100, Andreas Schwab wrote:
>>> "Martin Schwidefsky" <schwidefsky@de.ibm.com> writes:
>>>
>>> |> Does this mean that we have to make them GLIBC_2.0 versioned symbols
>>> |> although the earliest symbol set for s390x is GLIBC_2.2 ?
>>>
>>> This will be automatically handled.  Even many Versions files list
symbols
>>> under the GLIBC_2.0 version the shared library will not contain
versions
>>> prior to the earliest version as specified in shlib-versions.  See the
>>> generated file Versions.all in the build directory to see how it works.
>>
>> Though in this case it will cause only problems.
>> GCC libgcc-glibc.ver uses:
>>
>> %inherit GCC_3.0 GLIBC_2.0
>> GLIBC_2.0 {
>> ...
>>   __register_frame_info
>> ...
>> }
>>
>> So, either gcc needs to be changed so that for selected targets it will
use
>> different symbol for these symbols instead of GLIBC_2.0, or glibc needs
to
>> export them as GLIBC_2.0 unconditionally.
>
>So, what should be done?  Or what can be done easier?  If we fix it in
>GCC we should do it asap so that the fix will be in 3.1.

We have build a test driver with a glibc 2.2.5 and GLIBC_2.2 version for the
missing symbols. That works with gcc 2.95.3. Uli tried to switch to gcc 3.1
but that failed because gcc 3.1 defines GLIBC_2.0 symbols on its own. So either
we make these symbols gcc defines GLIBC_2.0 symbols (I really would hate to do
that, if it is possible at all), or convince gcc 3.1 that these symbols are
GLIBC_2.2 for s390x.

blue skies,
   Martin

Linux/390 Design & Development, IBM Deutschland Entwicklung GmbH
Schönaicherstr. 220, D-71032 Böblingen, Telefon: 49 - (0)7031 - 16-2247
E-Mail: schwidefsky@de.ibm.com