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] |
On Sat, Nov 17, 2001 at 10:59:24AM -0800, Ulrich Drepper wrote: > Jakub Jelinek <jakub@redhat.com> writes: > > > If __register_frame_info and similar registry is not present in > > glibc, this means all shared libs have to be linked against -lgcc_s > > Anad this is how it has to be. Otherwise the whole conceot of > libgcc_s is wrong and then you'll have to convince the gcc people. > glibc is not there to work around such decisions. Richard, can you please say your word here? Do you want /lib/libgcc_s.so.1 to be linked with every C shared library and every C program even on GLIBC 2.2.5+ systems? > > But what I'm worried more is the GCC_3.0 vs. GLIBC_2.2.5 thing which > > basically render this glibc change useless. > > Show me examples. Code. E.g. try the attached testcase (replace the compilers so that one is gcc 3.1 and one is gcc-2.96 (or 2.95, doesn't matter) and the third one can be equal to one of the two). Dies miserably when glibc has those symbols @ GLIBC_2.2.5, while works flawlessly if they are @ GCC_3.0. Jakub
Attachment:
test_eh.tar.bz2
Description: Binary data
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |