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] |
On Thu, Nov 09, 2000 at 05:58:39PM -0800, Ulrich Drepper wrote: > "H . J . Lu" <hjl@valinux.com> writes: > > > I'd like to resolve this: > > > > http://sources.redhat.com/ml/libc-hacker/2000-11/msg00057.html > > > > before it is too late. I think this bug may be unique to Linux. > > All tries of you to handle this I've seen so far are wrong. There Do you have any suggestions for my testcase? > must not be any assumption being made on the version names in > different DSOs. Initially we thought about using different names I disagree. If a definition from one library is designed to override the one from another library, I believe both name and version should match. Otherwise, we will see problems like my testcase. To take it further, assume one day we want GLIBC_2.2 for pread in libc and the one in linuxthreads has to be changed also, what do we do? > altogether but dropped the idea. > If we had done that, we might have seen thread applications failures long time ago. Why do we have both GLIBC_2_0 and GLIBC_2_1 for pthread_attr_init in libc? They are the same in libc. If the name doesn't matter, why bother with GLIBC_2_0 and GLIBC_2_1? -- H.J. Lu (hjl@valinux.com)
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |