On Thu, 31 Oct 2002, Alexander Kabaev wrote:
On Thu, 31 Oct 2002 12:20:14 -0500 (EST)
Daniel Eischen [EMAIL PROTECTED] wrote:
I wonder how it works for Solaris (you can see both the non-underscore
and single-underscore symbols resolve to the same thing)? Perhaps their
stubs in libc
Daniel Eischen wrote:
By default, ti_jump_table entries contain pointers to dummy function like
_return_zero if no threading library is loaded. When the threading library is
loaded, ti_jump_table is populated with new pointers to functions implemented
in threading library library. GDB did
On Wed, Oct 30, 2002 at 06:02:38PM -0800, Juli Mallett wrote:
Considering that I built the same applications and ran the same applications
fine a while ago, and we've had a binutils upgrade, and things don't break
on other systems, I'm inclined to assume there are linker bugs afoot, and
all
On Wed, 30 Oct 2002, Juli Mallett wrote:
* De: Terry Lambert [EMAIL PROTECTED] [ Data: 2002-10-30 ]
[ Subjecte: Re: [PATCH: libc]Re: gnome on current ]
Maybe the workaround for now is to make the symbols in libXThrStub.so
weak?
They *are* weak Terry. The problem
On Wed, 30 Oct 2002, Daniel Eischen wrote:
On Wed, 30 Oct 2002, Alexander Kabaev wrote:
On Wed, 30 Oct 2002 15:51:48 -0800
Terry Lambert [EMAIL PROTECTED] wrote:
NO.
If you have a library that's linked to a library containing string
symbols, then no other library gets a chance
On Thu, 31 Oct 2002, Alexander Kabaev wrote:
On Wed, 30 Oct 2002 22:25:12 -0500 (EST)
Daniel Eischen [EMAIL PROTECTED] wrote:
If last weak will win, the normal case when Xthrstub is loaded
_after_ libc_r will break. The only way to really fix this is to
export pthread_ symbols as
hi, there!
On Thu, Oct 31, 2002 at 12:39:10AM -0800, David O'Brien wrote:
Considering that I built the same applications and ran the same applications
fine a while ago, and we've had a binutils upgrade, and things don't break
on other systems, I'm inclined to assume there are linker bugs
On Thu, 31 Oct 2002, Alexander Kabaev wrote:
On Wed, 30 Oct 2002 22:25:12 -0500 (EST)
Daniel Eischen [EMAIL PROTECTED] wrote:
If last weak will win, the normal case when Xthrstub is loaded
_after_ libc_r will break. The only way to really fix this is to
export pthread_ symbols as
On Thu, 31 Oct 2002, Doug Rabson wrote:
On Thu, 31 Oct 2002, Alexander Kabaev wrote:
On Wed, 30 Oct 2002 22:25:12 -0500 (EST)
Daniel Eischen [EMAIL PROTECTED] wrote:
If last weak will win, the normal case when Xthrstub is loaded
_after_ libc_r will break. The only way to really
On Thu, 31 Oct 2002, Max Khon wrote:
hi, there!
On Thu, Oct 31, 2002 at 12:39:10AM -0800, David O'Brien wrote:
Considering that I built the same applications and ran the same applications
fine a while ago, and we've had a binutils upgrade, and things don't break
on other systems, I'm
* De: David O'Brien [EMAIL PROTECTED] [ Data: 2002-10-31 ]
[ Subjecte: Re: [PATCH: libc]Re: gnome on current ]
On Wed, Oct 30, 2002 at 06:02:38PM -0800, Juli Mallett wrote:
Considering that I built the same applications and ran the same applications
fine a while ago, and we've had
On Thu, 31 Oct 2002, Alexander Kabaev wrote:
On Wed, 30 Oct 2002 22:25:12 -0500 (EST)
Daniel Eischen [EMAIL PROTECTED] wrote:
If last weak will win, the normal case when Xthrstub is loaded
_after_ libc_r will break. The only way to really fix this is to
export pthread_ symbols as
On Thu, 31 Oct 2002, Doug Rabson wrote:
On Wed, 30 Oct 2002, Daniel Eischen wrote:
On Wed, 30 Oct 2002, Alexander Kabaev wrote:
On Wed, 30 Oct 2002 15:51:48 -0800
Terry Lambert [EMAIL PROTECTED] wrote:
NO.
If you have a library that's linked to a library containing
On Thu, 31 Oct 2002, Doug Rabson wrote:
On Thu, 31 Oct 2002, Alexander Kabaev wrote:
On Wed, 30 Oct 2002 22:25:12 -0500 (EST)
Daniel Eischen [EMAIL PROTECTED] wrote:
If last weak will win, the normal case when Xthrstub is loaded
_after_ libc_r will break. The only way to really
On Thu, 31 Oct 2002 09:08:12 -0500 (EST)
Daniel Eischen [EMAIL PROTECTED] wrote:
Cool. Then let's be consistent and follow Solaris all the way. Libc
on Solaris provides full set of pthread_? functions which in turn
call weakly defined _pthread_?? counterparts. libpthread in turn
provides
* De: Juli Mallett [EMAIL PROTECTED] [ Data: 2002-10-31 ]
[ Subjecte: Re: [PATCH: libc]Re: gnome on current ]
* De: David O'Brien [EMAIL PROTECTED] [ Data: 2002-10-31 ]
[ Subjecte: Re: [PATCH: libc]Re: gnome on current ]
On Wed, Oct 30, 2002 at 06:02:38PM -0800, Juli Mallett
On Thu, 31 Oct 2002, Daniel Eischen wrote:
On Thu, 31 Oct 2002, Doug Rabson wrote:
On Thu, 31 Oct 2002, Alexander Kabaev wrote:
On Wed, 30 Oct 2002 22:25:12 -0500 (EST)
Daniel Eischen [EMAIL PROTECTED] wrote:
If last weak will win, the normal case when Xthrstub is loaded
On Thu, 31 Oct 2002, Alexander Kabaev wrote:
On Thu, 31 Oct 2002 09:08:12 -0500 (EST)
Daniel Eischen [EMAIL PROTECTED] wrote:
Cool. Then let's be consistent and follow Solaris all the way. Libc
on Solaris provides full set of pthread_? functions which in turn
call weakly defined
On Thu, 31 Oct 2002 05:45:43 -0800
Juli Mallett [EMAIL PROTECTED] wrote:
* De: David O'Brien [EMAIL PROTECTED] [ Data: 2002-10-31 ]
[ Subjecte: Re: [PATCH: libc]Re: gnome on current ]
On Wed, Oct 30, 2002 at 06:02:38PM -0800, Juli Mallett wrote:
Considering that I built the same
On Thu, 31 Oct 2002, Alexander Kabaev wrote:
On Thu, 31 Oct 2002 05:45:43 -0800
Juli Mallett [EMAIL PROTECTED] wrote:
* De: David O'Brien [EMAIL PROTECTED] [ Data: 2002-10-31 ]
[ Subjecte: Re: [PATCH: libc]Re: gnome on current ]
On Wed, Oct 30, 2002 at 06:02:38PM -0800, Juli
On Thu, 31 Oct 2002, Daniel Eischen wrote:
On Thu, 31 Oct 2002, Alexander Kabaev wrote:
On Thu, 31 Oct 2002 09:08:12 -0500 (EST)
Daniel Eischen [EMAIL PROTECTED] wrote:
Cool. Then let's be consistent and follow Solaris all the way. Libc
on Solaris provides full set of pthread_?
I'll respond to two messages in one.
No, you stated that Solaris libpthread defines pthread_ symbols
strong. It doesn't. Perhaps you really meant _pthread_ symbols,
which is what you say above.
No, I meant a simple fact that Solaris provides weak definition for
both _pthread and pthread
On Thu, 31 Oct 2002, Doug Rabson wrote:
On Thu, 31 Oct 2002, Daniel Eischen wrote:
You can also play the libgcc game inside of libc for those applications
or libraries that are too lazy to do it for themselves. Have the
libc pthread stubs key on a weak reference to pthread_create and
On Thu, 31 Oct 2002, Daniel Eischen wrote:
On Thu, 31 Oct 2002, Doug Rabson wrote:
On Thu, 31 Oct 2002, Daniel Eischen wrote:
You can also play the libgcc game inside of libc for those applications
or libraries that are too lazy to do it for themselves. Have the
libc pthread stubs
On Thu, 31 Oct 2002, Doug Rabson wrote:
On Thu, 31 Oct 2002, Daniel Eischen wrote:
On Thu, 31 Oct 2002, Doug Rabson wrote:
On Thu, 31 Oct 2002, Daniel Eischen wrote:
You can also play the libgcc game inside of libc for those applications
or libraries that are too lazy to do it for
On Thu, 31 Oct 2002, Daniel Eischen wrote:
On Thu, 31 Oct 2002, Doug Rabson wrote:
On Thu, 31 Oct 2002, Daniel Eischen wrote:
On Thu, 31 Oct 2002, Doug Rabson wrote:
On Thu, 31 Oct 2002, Daniel Eischen wrote:
You can also play the libgcc game inside of libc for those
On Thu, 31 Oct 2002, Doug Rabson wrote:
On Thu, 31 Oct 2002, Daniel Eischen wrote:
On Thu, 31 Oct 2002, Doug Rabson wrote:
We only use _pthread_* in libc, so it doesn't break libc unless
they provide strong symbols for _pthread_*. Our implementation
relies on the use of single
On Thu, 31 Oct 2002, Daniel Eischen wrote:
On Thu, 31 Oct 2002, Doug Rabson wrote:
On Thu, 31 Oct 2002, Daniel Eischen wrote:
I don't see how that can be. _pthread_mutex_lock() in libc_r calls
init_static_private(), not init_static().
That was it (I single stepped through this in
On Thu, 31 Oct 2002 12:20:14 -0500 (EST)
Daniel Eischen [EMAIL PROTECTED] wrote:
I wonder how it works for Solaris (you can see both the non-underscore
and single-underscore symbols resolve to the same thing)? Perhaps their
stubs in libc pull the libgcc trick?
Solaris libc uses something
On Thu, 31 Oct 2002, Alexander Kabaev wrote:
On Thu, 31 Oct 2002 12:20:14 -0500 (EST)
Daniel Eischen [EMAIL PROTECTED] wrote:
I wonder how it works for Solaris (you can see both the non-underscore
and single-underscore symbols resolve to the same thing)? Perhaps their
stubs in libc
On Thu, 31 Oct 2002, Daniel Eischen wrote:
This is better, although it has two stubs for each routine. Adding
a weak definition from pthread_foo() to _pthread_foo() (note the
lack of _stub) doesn't do the same thing?
Ok, this version works and seems to be a reasonably tidy solution, at
least
On Thu, 31 Oct 2002, Doug Rabson wrote:
On Thu, 31 Oct 2002, Daniel Eischen wrote:
This is better, although it has two stubs for each routine. Adding
a weak definition from pthread_foo() to _pthread_foo() (note the
lack of _stub) doesn't do the same thing?
Ok, this version works and
Doug Rabson wrote:
On Thu, 31 Oct 2002, Daniel Eischen wrote:
It almost doesn't matter which of the solutions we use as long as we do
something. What we currently have is clearly wrong but I'll list it along
with the others. Solutions so far proposed are:
[ ... ]
2. Define weak _pthread_*
Alexander Kabaev wrote:
Wrong. Solaris and Linux differ from FreeBSD each in its own way.
Linuxprovides strong pthread definitions in libpthread
Solaris provides weak pthread and _pthread definitions in Libc
with libpthread providing strong _pthread and weak pthread
We are
Daniel Eischen wrote:
We also have an additional requirement in libc. Our uses of
_pthread_* in libc must correspond to the [single underscore]
_pthread_* in libc_r (and libpthread eventually). All references
to [non underscore] pthread_* routines must correspond to the
[two underscore]
Doug Rabson wrote:
Now I'm really confused. I can't see how this can work properly. Imagine
the following scenario:
An application 'base' is linked against libc and is not threaded. This
application loads a plugin 'Xplug.so' via dlopen(). Xplug doesn't use
threads but it does link against
Alexander Kabaev wrote:
By default, ti_jump_table entries contain pointers to dummy function like
_return_zero if no threading library is loaded. When the threading library is
loaded, ti_jump_table is populated with new pointers to functions implemented
in threading library library. GDB did
On Wed, 30 Oct 2002, Terry Lambert wrote:
Doug Rabson wrote:
All you have to do is create a situation where a shared object that links
to libc_r is loaded after libX11 and the thing breaks into little pieces.
So let's dike out libXThrStub.so, and be done with it.
I think the
Daniel Eischen wrote:
That's bizarre... it's defined in libc_r, so there's no reason for
the omission in libc.
I only added stubs that I thought the implementation of libc used
(or would use).
Makes sense.
Actually, it looks like most of this could be done with macros,
including the
On Wed, 30 Oct 2002, Terry Lambert wrote:
Daniel Eischen wrote:
That's bizarre... it's defined in libc_r, so there's no reason for
the omission in libc.
I only added stubs that I thought the implementation of libc used
(or would use).
Makes sense.
Actually, it looks like most of
Doug Rabson wrote:
On Wed, 30 Oct 2002, Terry Lambert wrote:
Daniel Eischen wrote:
Patch looks correct.
Please commit? 8-).
Well I made a libc with this patch and rebuilt XFree86-4-libraries without
libXThrStub but I ran into problems compiling the clients. The clients
*require*
On Wed, 30 Oct 2002, Doug Rabson wrote:
On Wed, 30 Oct 2002, Terry Lambert wrote:
Daniel Eischen wrote:
That's bizarre... it's defined in libc_r, so there's no reason for
the omission in libc.
I only added stubs that I thought the implementation of libc used
(or would use).
On Wed, 30 Oct 2002, Daniel Eischen wrote:
On Wed, 30 Oct 2002, Doug Rabson wrote:
On Wed, 30 Oct 2002, Terry Lambert wrote:
Daniel Eischen wrote:
That's bizarre... it's defined in libc_r, so there's no reason for
the omission in libc.
I only added stubs that I thought
On Wed, 30 Oct 2002, Terry Lambert wrote:
Doug Rabson wrote:
On Wed, 30 Oct 2002, Terry Lambert wrote:
Daniel Eischen wrote:
Patch looks correct.
Please commit? 8-).
Well I made a libc with this patch and rebuilt XFree86-4-libraries without
libXThrStub but I ran into
On Wed, 30 Oct 2002, Doug Rabson wrote:
On Wed, 30 Oct 2002, Terry Lambert wrote:
Doug Rabson wrote:
On Wed, 30 Oct 2002, Terry Lambert wrote:
Daniel Eischen wrote:
Patch looks correct.
Please commit? 8-).
Well I made a libc with this patch and rebuilt
Doug Rabson wrote:
On Wed, 30 Oct 2002, Daniel Eischen wrote:
Well, it must have the same problem with Solaris then. Somehow,
you've got to force it to link libc_r before libc...
The only way I can see to do that is to link libX11, libXt and friends
against libc_r.
What this comes down
Doug Rabson wrote:
You need to link the library against libc_r.so instead of libXThrStub.so.
Probably not. Doing that breaks the existing 'feature' of being able to
use X11 in entirely non-threaded programs. I'm not sure whether that is
acceptable. It also stops programs from being able to
Doug Rabson wrote:
I think the only sensible solution to this problem is for libraries which
provide an actual pthreads implementation (rather than a set of stubs) to
define strong symbols. Wierd debugging wrappers can still be achieved via
some dlopen/dlsym hackery.
For what its worth,
On Wed, 30 Oct 2002, Terry Lambert wrote:
Doug Rabson wrote:
You need to link the library against libc_r.so instead of libXThrStub.so.
Probably not. Doing that breaks the existing 'feature' of being able to
use X11 in entirely non-threaded programs. I'm not sure whether that is
On Wed, 30 Oct 2002, Terry Lambert wrote:
Doug Rabson wrote:
I think the only sensible solution to this problem is for libraries which
provide an actual pthreads implementation (rather than a set of stubs) to
define strong symbols. Wierd debugging wrappers can still be achieved via
Doug Rabson wrote:
You can't have a library that's sort of threaded and sort of not
threaded: pick one.
Yes you can - libX11 is *thread safe* but doesn't create threads. When a
real pthreads implementation is present, libX11 uses its implementation of
mutex, cond etc. to ensure its own
Doug Rabson wrote:
For what its worth, doing this (defining strong pthread_* symbols in
libc_r) makes everything work fine, with or without libXThrStub.
No, this would be bad. There's some justification for not
doing this, in allowing programs linked againts libraries linked
against
* De: Terry Lambert [EMAIL PROTECTED] [ Data: 2002-10-30 ]
[ Subjecte: Re: [PATCH: libc]Re: gnome on current ]
Maybe the workaround for now is to make the symbols in libXThrStub.so
weak?
They *are* weak Terry. The problem is that every bloody definition is weak
so the linker
On Wed, 30 Oct 2002 15:51:48 -0800
Terry Lambert [EMAIL PROTECTED] wrote:
NO.
If you have a library that's linked to a library containing string
symbols, then no other library gets a chance to replace to symbols
with its own strong symbols. The first strong symbol always wins,
and the
On Wed, 30 Oct 2002, Doug Rabson wrote:
On Wed, 30 Oct 2002, Terry Lambert wrote:
You need to link the library against libc_r.so instead of libXThrStub.so.
Probably not. Doing that breaks the existing 'feature' of being able to
use X11 in entirely non-threaded programs. I'm not sure
On Wed, 30 Oct 2002, Alexander Kabaev wrote:
On Wed, 30 Oct 2002 15:51:48 -0800
Terry Lambert [EMAIL PROTECTED] wrote:
NO.
If you have a library that's linked to a library containing string
symbols, then no other library gets a chance to replace to symbols
with its own strong
On Wed, 30 Oct 2002 22:25:12 -0500 (EST)
Daniel Eischen [EMAIL PROTECTED] wrote:
If last weak will win, the normal case when Xthrstub is loaded
_after_ libc_r will break. The only way to really fix this is to
export pthread_ symbols as strong in libc_r. Exporting them as weak
sounds like
Alexander Kabaev wrote:
If last weak will win, the normal case when Xthrstub is loaded _after_ libc_r
will break. The only way to really fix this is to export pthread_ symbols as
strong in libc_r. Exporting them as weak sounds like is a mistake which
should be fixed.
You people keep saying
58 matches
Mail list logo
