Before you think this is old: I didn't yet grasp the mutex code, but it
still looks _very_ similar and see the last paragraph of this mail.
Someone please check this before release? I haven't yet tried the code
example given. Can this bug surely & safely be closed?
Sorry, i really didn't have the time to examine this yet :-/
Debian Bug report logs - [1]#78585
libgii0: needs to dlopen the soname of libpthread.so
Date: Sat, 02 Dec 2000 18:33:22 +0100
Delivered-To: [EMAIL PROTECTED]
Package: libc6-i586
Version: 2.2-4
Severity: normal
I have some troubles with libc6-i586: heroes-ggi-0.7 doesn't work
when libc6-i586 is installed. It runs well with the standard libc6.
I played a bit with this. In short, it appears to be due to the fact
that the program loads two differents versions of libpthread.
1) heroes is linked with -lgii and -lpthread (==
/lib/i586/libpthread.so.0)
2) libgii does a dlopen("libpthread.so", RTLD_LAZY)
which actually open /usr/lib/libpthread.so (==
/lib/libpthread.so.0).
Here is how to reproduce. The sample program compiled below never
terminates because for some reason pthread_create never returns (I
suspect this is due the joint use of those two different pthread
libraries).
You needs to install package libgii0-dev to compile th.c.
=====
% cat th.c
#include <unistd.h>
#include <pthread.h>
#include <stdio.h>
#include <ggi/gii.h>
pthread_t foo_thread;
static void *
foo (void *arg)
{
puts ("entering foo");
sleep (2);
puts ("exiting foo");
return 0;
}
int
main (void)
{
giiInit (); /* this calls dlopen("libpthread.so", RTLD_LAZY)
internally */
pthread_create (&foo_thread, 0, foo, 0);
/* control never goes here */
puts ("thread foo created");
pthread_join (foo_thread, 0);
return 0;
}
% gcc th.c -o th -lpthread -lgii
% ./th
entering foo
exiting foo
^C
% strace ./th 2>&1 | grep thread
open("/lib/i586/libpthread.so.0", O_RDONLY) = 3
open("/usr/lib/libpthread.so", O_RDONLY) = 3
^C
%
=====
You may want to reassign this bug to libggi0. I'm not able to decide
whether libgii0 is culprit or not. The fact that
/usr/lib/libpthread.so is installed by libc6-dev (and not libc6)
probably means that giiInit() should NOT dlopen it, but shoudl rather
dlopen "libptread.so.0" or something else. In doubt, I'm submiting
this here, because the libgii0's maintainer does not appear to be
active.
Thanks.
-- System Information
Debian Release: woody
Kernel Version: Linux phobos 2.4.0-test10 #6 Fri Nov 10 11:06:04 CET
2000 i586
unknown
Versions of the packages libc6-i586 depends on:
ii libc6 2.2-4 GNU C Library: Shared libraries and
Timezone
_________________________________________________________________
Message received at [EMAIL PROTECTED]:
Date: Fri, 29 Dec 2000 14:55:25 -0500
Delivered-To: [EMAIL PROTECTED]
We believe that the bug you reported is fixed in the latest version of
glibc, which has been installed in the Debian FTP archive:
_________________________________________________________________
Message received at [EMAIL PROTECTED]:
Subject: 78585 is *not* fixed (please reopen)
Date: 30 Dec 2000 16:23:47 +0100
>>> "Debian" == Debian Bug Tracking System <[EMAIL PROTECTED]>
writes:
[...]
Debian> * Could not reproduce. My test program showed that it resolved
the
Debian> libpthread properly. I am going to assume user error, or some
Debian> funkiness on the user's system. closes: #78585
I can reproduce it really easily, on (three) differents hosts,
not all beeing mine (which means they are not all configured
likewise and I doubt there is the same funkiness in each of them...).
You'll find below a full transcript which shows how the same
program can have a different behavior whether libc6-i686 (or -i586)
is installed or not.
ii libc6 2.2-6 GNU C Library: Shared libraries and
ii libgii0 0.6-1.1 General Input Interface runtime
/tmp # cat >th.c
#include <unistd.h>
#include <pthread.h>
#include <stdio.h>
#include <ggi/gii.h>
pthread_t foo_thread;
static void *
foo (void *arg)
{
puts ("entering foo");
sleep (2);
puts ("exiting foo");
return 0;
}
int
main (void)
{
giiInit (); /* this calls dlopen("libpthread.so", RTLD_LAZY)
internally */
pthread_create (&foo_thread, 0, foo, 0);
/* control never goes here */
puts ("thread foo created");
pthread_join (foo_thread, 0);
return 0;
}
/tmp # gcc th.c -o th -lpthread -lgii
/tmp # ./th
entering foo
exiting foo
^C
/tmp # strace ./th 2>&1 | grep thread
open("/lib/i686/libpthread.so.0", O_RDONLY) = 3
open("/usr/lib/libpthread.so", O_RDONLY) = 3
^C
/tmp # ldd th
libpthread.so.0 => /lib/i686/libpthread.so.0 (0x40020000)
libgii.so.0 => /usr/lib/libgii.so.0 (0x40037000)
libc.so.6 => /lib/i686/libc.so.6 (0x4003e000)
libgg.so.0 => /usr/lib/libgg.so.0 (0x4015f000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
libdl.so.2 => /lib/i686/libdl.so.2 (0x40164000)
/tmp # apt-get remove libc6-i686
/tmp # ./th
thread foo created
entering foo
exiting foo
/tmp # strace ./th 2>&1 | grep thread
open("/lib/i686/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file
or direct
ory)
open("/lib/i686/mmx/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such
file or di
rectory)
open("/lib/i686/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file
or direct
ory)
open("/lib/mmx/libpthread.so.0", O_RDONLY) = -1 ENOENT (No such file or
directo
ry)
open("/lib/libpthread.so.0", O_RDONLY) = 3
open("/usr/lib/libpthread.so", O_RDONLY) = 3
write(1, "entering foo\nthread foo created\n"..., 44entering foo
thread foo created
/tmp # ldd th
libpthread.so.0 => /lib/libpthread.so.0 (0x40020000)
libgii.so.0 => /usr/lib/libgii.so.0 (0x40036000)
libc.so.6 => /lib/libc.so.6 (0x4003d000)
libgg.so.0 => /usr/lib/libgg.so.0 (0x40148000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
libdl.so.2 => /lib/libdl.so.2 (0x4014d000)
My understanding is that the bug can easily be resolved by
patching libgii0 so that it dlopen("libpthread.so.0",...) rather
then dlopen("libpthread.so",...). Because
/usr/lib/libpthread.so is symlink which *always* (is that
correct?) points to /lib/libpthread.so.0, but the latter library
is *not always* the right library to load (here,
/lib/i686/libpthread.so.0 should be prefered).
But maybe there are some other libraries that
dlopen("libpthread.so",...) too. I'm not competant to say
whether they are wrong or right to play so. Would it be wrong
to have the libc6-i686 package to overwrite
/usr/lib/libpthread.so to point towards
/lib/i686/libpthread.so.0 ? That would also solve the problem,
I guess.
Thank for you patience.
--
Alexandre Duret-Lutz
_________________________________________________________________
Message received at [EMAIL PROTECTED]:
Subject: Re: 78585 is *not* fixed (please reopen)
reopen 78585
retitle 78585 ggi: needs to dlopen the soname of libpthread.so
That's the whole point. You cannot expect to dlopen a .so, and get
things right. Just imagine dlopen'ing "libc.so"!? The ggi library needs
to dlopen *with* the soname, not the .so, for two reasons:
- Opening the .so does not ensure it gets the library it intends.
Suppose there are three pthread libraries, each with a different
soname. GGI will have no idea which one it opens, so wont know which
interface it will be using.
- Secondly, opening the .so means that the ggi runtime library *depends*
on libc6-dev being installed, since that is the package that contains
the .so symlink. Without that, it wont be able to open
"libpthread.so", since that name does not exist.
I am reopening this bug at your request, but reassigning it to libggi.
GGI Maintainer: You need to check this with upstream, because you will
need a configure.in test to see what the soname of the pthread library
is. Shouldn't be that hard, but it will ensure things continue to work
properly when linuxthreads changes it's interface and it's soname.
As far Debian is concerned, upgrading to libgii-0.7 should be
enough. They have added a configure option:
--enable-mutexes=TYPE force the kind of mutexes to use
(builtin, pthread, dynpthread)
which default to `builtin' so libgii no longuer needs to load
libpthread dynamically. (However libgii will still dlopen
libpthread.so when configured with --enable-mutexes=dynpthread.)
--
Alexandre Duret-Lutz
_________________________________________________________________
References
5. http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=libgii
