I am working on SuSE 9.1 Prof. and SuSE Linux Enterprise Server 9.
According to the manuals both versions should be using NPTL threading
implemenation as default and have optional support for older
Linuxthreads implementation.
I've found some strange issues which appear to be bugs to me. If would
appreciate to hear your opinions about it.
1. There seem to libraries at
(a) /lib/libpthread.so.0
(b) /lib/tls/libpthread.so.0
(c) /usr/lib/libpthread.so
where (c) is only a textfile (GNU ld script) which points to (a).
Strangely it appears that (a) is the Linuxthreads implementation
while (b) is the true NPTL implemenation. There are also some other
additional libs in /lib/tls (libc.so etc.).
Also there seem to be two implementations for header files, e.g.
pthread.h in
(d) /usr/include/pthread.h
(e) /usr/include/nptl/pthread.h
There are some more headerfiles in /usr/include/nptl and subdirs.
2. Although SuSE claims to use NPTL as default through (c) library
(a) is used for linking tasks like in
cc -o x x.c -lpthread
as can be found out using 'strace -F -f -o /tmp/out ...' on this
command.
3. Also without further options, include file (d) is used for
compilation (which is a Linuxthread and not a NPTL one as shown
when displaying the file)
4. However, when executing a so called application, the NPTL thread
library is used, as can be shown with 'ldd -r x', e.g.
...
libpthread.so.0 => /lib/tls/libpthread.so.0 (0x40030000)
...
To me this appears to be a strange approach which doesn't work
correctly for all cases.
For example, the NPTL implementation fully supports the use of shared
mutexes. Now if you compile the following program
--- snip --- snap ---
#include <stdio.h>
#include <pthread.h>
#include <unistd.h>
int
main(void)
{
int r;
#ifdef _POSIX_THREAD_PROCESS_SHARED
printf("#define _POSIX_THREAD_PROCESS_SHARED set!\n");
r = sysconf(_POSIX_THREAD_PROCESS_SHARED);
printf("sysconf(_POSIX_THREAD_PROCESS_SHARED) = %d\n", r);
#else
printf("#define _POSIX_THREAD_PROCESS_SHARED not set!\n");
#endif
}
--- snip --- snap ---
just with
cc -o x x.c -lpthread
on executing 'x' you get
#define _POSIX_THREAD_PROCESS_SHARED not set!
which is not what NPTL supports. To compile this correctly you need to
use
cc -I/usr/include/nptl -o e e.c -lpthread
so that it uses the correct NPTL header files. In this case you get
#define _POSIX_THREAD_PROCESS_SHARED set!
sysconf(_POSIX_THREAD_PROCESS_SHARED) = -1
Now the define is there (and the functionality with shared mutexes
works, as I have tested), but apparently sysconf() doesn't return the
correct attribute (as it should as written in /usr/include/unistd.h).
Another more severe problem is that using the old Linuxthreads
implementation doesn't allow to use all functionality of NPTL as the
following example shows (it's just to show linkage errors, doesn't do
anything useful):
--- snip --- snap ---
#include <pthread.h>
int
main(void)
{
pthread_cleanup_push(NULL, NULL);
pthread_cleanup_pop(0);
}
--- snip --- snap ---
If you compile this correctly with
cc -I/usr/include/nptl -o f f.c -lpthread
as you need for full NPTL functionality as shown above, you get
/tmp/cc2dpGGJ.o(.text+0x55): In function `main':
: undefined reference to `__pthread_register_cancel'
/tmp/cc2dpGGJ.o(.text+0x5d): In function `main':
: undefined reference to `__pthread_unregister_cancel'
collect2: ld returned 1 exit status
because this functions do not exist in the old library (a) while they
do well exist in the NPTL implementation in (c) as e.g.
nm /lib/tls/libpthread.so.0 | fgrep __pthread_register_cancel
clearly shows:
...
00009690 T __pthread_register_cancel
...
I have found no way to get all NPTL functionality (forcing me to use
-I/usr/include/nptl) and linking it correctly.
I have also tried to put all libs from /usr/lib into a new directory
and replace the necessary ones by those in /lib/tls but then I get
other problems.
I have found nothing about all this in the SuSE documentation yet
(they only tell me how to get 'ld' to use Linuxthreads library when
running a process), thus I reported these topics as bugs via technical
feedback.
All hints on how to proceed are appreciated.
Regards,
Guido
> I am working on SuSE 9.1 Prof. and SuSE Linux Enterprise Server 9.
>
> According to the manuals both versions should be using NPTL threading
> implemenation as default and have optional support for older
> Linuxthreads implementation.
>
> I've found some strange issues which appear to be bugs to me. If would
> appreciate to hear your opinions about it.
That won't directly answer your problem, I am afraid. But in order to
termine which Pthreads your system is using by default, you might want
to read thread #39 of Kapser Dupont unofficial cold.* FAQ:
http://www.daimi.au.dk/~kasperd/comp.os.linux.development.faq.html#nptl
I hope I shall get the chance to install SuSE v9.1 on one of my
machine... And then come back to you original question.
Regards,
Loic.
Loic Domaigne <loic...@gmx.net> wrote:
> That won't directly answer your problem, I am afraid. But in order
> to termine which Pthreads your system is using by default, you might
> want to read thread #39 of Kapser Dupont unofficial cold.* FAQ:
Thanks for the hint. I've checked and confirmed that the
/lib/tls/libpthread.so.0 is the NPTL lib and /lib/pthread.so.0 is the
Linuxthreads lib.
The results are (with no special environment):
getconf GNU_LIBPTHREAD_VERSION
-> NPTL 0.61
`ldd ./e | grep libc.so.6 | cut -d' ' -f 3` | egrep -i \
'linuxthreads|nptl'
-> NPTL 0.61 by Ulrich Drepper
(ldd reports /lib/tls/libpthread.so.0 to be used)
But for linking it uses the Linuxthreads lib (which is the problem).
BTW, to run with old Linuxthreads one must set
export LD_ASSUME_KERNEL=2.2.5
then the above commands report 'linuxthreads-0.10' or
'linuxthreads-0.10 by Xavier Leroy' respectively and ldd indicates
/lib/libpthread.so.0 to be used.
> I hope I shall get the chance to install SuSE v9.1 on one of my
> machine... And then come back to you original question.
That would be great.
Regards,
Guido
Hi,
Does -L/lib/tls help ?
Regards
Where did '-lpthread' come from?
>> just with
>> cc -o x x.c -lpthread
>>
>> on executing 'x' you get
>>
>> #define _POSIX_THREAD_PROCESS_SHARED not set!
Again, where is '-lpthread' coming from?
>> which is not what NPTL supports. To compile this correctly you need to
>> use
>>
>> cc -I/usr/include/nptl -o e e.c -lpthread
>>
>> so that it uses the correct NPTL header files. In this case you get
>>
>> #define _POSIX_THREAD_PROCESS_SHARED set!
>> sysconf(_POSIX_THREAD_PROCESS_SHARED) = -1
Are you sure you want to create executables that won't work on
platforms that can't support NPTL? Are you sure that's what you want by
default?
You need to read your platform documentation.
DS
> >> 2. Although SuSE claims to use NPTL as default through (c) library
> >> (a) is used for linking tasks like in
> >>
> >> cc -o x x.c -lpthread
> Where did '-lpthread' come from?
Aaaah, David. Thanks you! It didn't noticed the '-lpthread' when I read
the original post...
Guido, could you try to compile with '-pthread' (assuming that the
compiler behind the generic 'cc' is indeed gcc). Otherwise, read the
corresponding manual of your C compiler in order to enable
"(POSIX) threading support".
And normally, you should only
#include <pthread.h> to make it work...
So Long,
Loic.
--
Article posté via l'accès Usenet http://www.mes-news.com
Accès par Nnrp ou Web
David Schwartz <dav...@webmaster.com> wrote:
>>> 2. Although SuSE claims to use NPTL as default through (c) library
>>> (a) is used for linking tasks like in
>>>
>>> cc -o x x.c -lpthread
>
> Where did '-lpthread' come from?
of course it was added by me since we do need the POSIX threading
functionality and this is the normal procedure to get it as I know
from other operating systems, e.g. Solaris etc.
> Are you sure you want to create executables that won't work on
> platforms that can't support NPTL?
Yes, I am.
I need POSIX thread functionality that is not supported by
Linuxthreads but by NPTL, especially the process-shared
synchronization (mutexes and conditional stuff in shared memory). This
is available in NPTL as signalled by the presence of the
_POSIX_THREAD_PROCESS_SHARED define in
/usr/include/nptl/bits/posix_opt.h.
> Are you sure that's what you want by default?
Yes.
> You need to read your platform documentation.
I would read it, if I knew it existed. All I could find is the
statement that SuSE 9.1 / SLES 9 is now using NPTL as default and how
to reactivate Linuxthreads just for execution (by setting an
LD_ASSUME_KERNEL environment).
Regards,
Guido
No, the error message remain the same.
Regards,
Guido
Loic Domaigne <loic...@gmx.net> wrote:
> Guido, could you try to compile with '-pthread' (assuming that the
> compiler behind the generic 'cc' is indeed gcc). Otherwise, read the
> corresponding manual of your C compiler in order to enable
> "(POSIX) threading support".
The GCC manpage lists the '-pthread' as machine-specific option for
RS/6000 and PowerPC - but I am on a Intel i686.
However, even when I try with '-pthread' I can see the internal 'ld'
gets called with just the '-lpthread' when invoking an 'strace -F -f
-v -o /tmp/mystrace.out' on the compiler command below.
cc -I/usr/include/nptl -o d d.c -pthread
/tmp/ccwsDshf.o(.text+0x55): In function `main':
: undefined reference to `__pthread_register_cancel'
/tmp/ccwsDshf.o(.text+0x5d): In function `main':
: undefined reference to `__pthread_unregister_cancel'
collect2: ld returned 1 exit status
This doesn't work, too.
> And normally, you should only
> #include <pthread.h> to make it work...
This is exactly what I have in my code (see second code example).
Regards,
Guido
>> Where did '-lpthread' come from?
> of course it was added by me since we do need the POSIX threading
> functionality and this is the normal procedure to get it as I know
> from other operating systems, e.g. Solaris etc.
The '-lpthread' flag might be correct on some platforms, but it is a
platform-specific flag. You need to read the documentation for your
platform/implementation to find the correct way to get a POSIX pthreads
compliant environment.
I would be very surprised if SuSE didn't provide documentation on how
to use their pthreads implementation!
DS
For the second problem, you have to do link manually. For example,
/usr/lib/gcc-lib/i586-suse-linux/3.3.3/collect2 --eh-frame-hdr -m
elf_i386 -dynamic-linker /lib/ld-linux.so.2
/usr/lib/gcc-lib/i586-suse-linux/3.3.3/../../../crt1.o
/usr/lib/gcc-lib/i586-suse-linux/3.3.3/../../../crti.o
/usr/lib/gcc-lib/i586-suse-linux/3.3.3/crtbegin.o
-L/usr/lib/gcc-lib/i586-suse-linux/3.3.3
-L/usr/lib/gcc-lib/i586-suse-linux/3.3.3/../../../../i586-suse-linux/lib
-L/usr/lib/gcc-lib/i586-suse-linux/3.3.3/../../.. thr2.o -lgcc -lgcc_eh
/lib/tls/libpthread.so.0 /lib/tls/libc.so.6 -lc -lgcc -lgcc_eh
/usr/lib/gcc-lib/i586-suse-linux/3.3.3/crtend.o
/usr/lib/gcc-lib/i586-suse-linux/3.3.3/../../../crtn.o
will be ok, if your program's name is thr2 too. I think SUSE should
toke the resposibility to fix this problem.