This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Jakub Jelinek <jakub@redhat.com> writes: > 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. Andreas -- Andreas Jaeger SuSE Labs aj@suse.de private aj@arthur.inka.de http://www.suse.de/~aj
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |