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]

Re: glibc 2.2 and versions in libc and linuxthreads


On Thu, Nov 09, 2000 at 06:09:20PM -0800, H . J . Lu wrote:
> 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?
> 

Please also take a look at elf/Versions. We have made sure that symbols
in ld.so overridden by libc.so have the same name and version. We
simply cannot have different version names in different DSOs and expect
one will always override the other.

Here is my revised patch. If we don't want pthread applications linked
against glibc 2.2 to fail silently under 2.1, we can drag in GLIBC_2_2
so that they will always fail. I think it is a small price to pay,
comparing with some pthread applications fail silently under glibc 2.2.
I hope this issue will be resolved before it is too late.


-- 
H.J. Lu (hjl@valinux.com)
---
2000-11-10  H.J. Lu  <hjl@gnu.org>

	* linuxthreads/Versions (libpthread:GLIBC_2.2): Move pread,
	__pread64, pread64, pwrite, __pwrite64, pwrite64, lseek64 and 
	open64 to ...
	(libpthread:GLIBC_2.1): Here.

	* csu/init.c (glibc_2_2): New. Drag in GLIBC_2.2 for
	pthread applications.

Index: linuxthreads/Versions
===================================================================
RCS file: /work/cvs/gnu/glibc/linuxthreads/Versions,v
retrieving revision 1.1.1.5
diff -u -p -r1.1.1.5 Versions
--- linuxthreads/Versions	2000/09/11 22:11:04	1.1.1.5
+++ linuxthreads/Versions	2000/11/10 17:14:26
@@ -113,6 +113,10 @@ libpthread {
     # helper functions
     __libc_current_sigrtmin; __libc_current_sigrtmax;
     __libc_allocate_rtsig;
+
+    # For the cancelation wrappers.
+    pread; __pread64; pread64; pwrite; __pwrite64; pwrite64; lseek64;
+    open64;
   }
   GLIBC_2.1.1 {
     sem_close; sem_open; sem_unlink;
@@ -123,8 +127,7 @@ libpthread {
   }
   GLIBC_2.2 {
     # For the cancelation wrappers.
-    pread; __pread64; pread64; pwrite; __pwrite64; pwrite64; lseek64;
-    open64; __open64;
+    __open64;
 
     __res_state;
 
Index: csu/init.c
===================================================================
RCS file: /work/cvs/gnu/glibc/csu/init.c,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 init.c
--- csu/init.c	2000/05/21 21:10:57	1.1.1.1
+++ csu/init.c	2000/11/10 19:25:08
@@ -33,4 +33,12 @@
 /* This records which stdio is linked against in the application. */
 const int _IO_stdin_used = _G_IO_IO_FILE_VERSION;
 
+/* Since we have to add pread, __pread64, pread64, pwrite, __pwrite64,
+   pwrite64, lseek64 and open64 to libpthread:GLIBC_2.1 in glibc 2.2,
+   we have to make sure pthread applications linked against glibc 2.2
+   will fail to run under glibc 2.1 by dragging in GLIBC_2.2 for
+   pthread applications. */
+extern void __pthread_initialize_minimal (void) __attribute__ ((weak));
+static const void * const glibc_2_2 __attribute__ ((unused))
+  = (void *) &__pthread_initialize_minimal;
 #endif

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]