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. G
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 i
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
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 agai
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
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
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
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 w
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
lea
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 i
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, 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 throug
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 u
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
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 laz
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 pthre
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
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, 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 se
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 ]
&g
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:
&
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
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 Xth
* 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, 2
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
> >
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 onl
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
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_ s
* 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
> > f
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
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
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_ sy
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 b
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_ sy
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
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?
&g
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
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 sayin
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
> > sou
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 ow
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
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
* 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
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 linke
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
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
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
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 i
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 abl
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 com
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 pa
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
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 a
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
>
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
>
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 loo
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 th
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.
> >
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 only stub which it defines that libc.so
On Tue, 29 Oct 2002, Terry Lambert wrote:
> Doug Rabson wrote:
> > The point is that with the current setup of the XFree86-4-libraries port,
> > you don't have any choice, since libX11 links to libXThrStub. This is the
> > key problem, IMHO. I have a machine running RedHat 8.0 and they don't have
On Tue, 29 Oct 2002, Terry Lambert wrote:
> Doug Rabson wrote:
> > The point is that with the current setup of the XFree86-4-libraries port,
> > you don't have any choice, since libX11 links to libXThrStub. This is the
> > key problem, IMHO. I have a machine running RedHat 8.0 and they don't have
Doug Rabson wrote:
> The point is that with the current setup of the XFree86-4-libraries port,
> you don't have any choice, since libX11 links to libXThrStub. This is the
> key problem, IMHO. I have a machine running RedHat 8.0 and they don't have
> any such thing. On RedHat, libXThrStub doesn't ev
On Tue, 29 Oct 2002, Terry Lambert wrote:
> Doug Rabson wrote:
> > On investigating one of the crashes more carefully, I discovered that all
> > calls to pthread_*() were being resolved to stubs in libXThrStub.so in
> > spite of the fact that libc_r was also loaded. This caused problems for
> > e.
Doug Rabson wrote:
> > When a symbol is defined in multiple libraries, the first library
> > wins. That's how it has always been in Unix, for archive libraries
> > and for shared libraries.
>
> This is a big problem then since X11.so links to XThrStub.so. This means
> that XThrStub will be ahead
Doug Rabson wrote:
> On investigating one of the crashes more carefully, I discovered that all
> calls to pthread_*() were being resolved to stubs in libXThrStub.so in
> spite of the fact that libc_r was also loaded. This caused problems for
> e.g. flockfile which failed to initialise its mutex (ut
Daniel Eischen writes:
> > It might have been slightly clearer if the _foo and __foo names had been
> > reversed, so that "foo" always weakly referenced "_foo" whether or not
> > the function was a cancellation point. But that would have probably
> > caused a lot of changes in existing code (?).
>
On Tue, 29 Oct 2002, Archie Cobbs wrote:
> John Polstra writes:
> > > > I think it would work if the symbol were defined strongly in libc_r.
> > >
> > > I think so too. I was trying to work out why this wasn't how things were
> > > done already. FWIW, linux's libpthread appears to be defining the
John Polstra writes:
> > > I think it would work if the symbol were defined strongly in libc_r.
> >
> > I think so too. I was trying to work out why this wasn't how things were
> > done already. FWIW, linux's libpthread appears to be defining the
> > pthread_* symbols strongly.
>
> I think the we
On Tue, 29 Oct 2002, John Polstra wrote:
> In article <[EMAIL PROTECTED]>,
> Doug Rabson <[EMAIL PROTECTED]> wrote:
> > On Tue, 29 Oct 2002, John Polstra wrote:
> > > I think it would work if the symbol were defined strongly in libc_r.
> >
> > I think so too. I was trying to work out why this was
In article <[EMAIL PROTECTED]>,
Doug Rabson <[EMAIL PROTECTED]> wrote:
> On Tue, 29 Oct 2002, John Polstra wrote:
> > I think it would work if the symbol were defined strongly in libc_r.
>
> I think so too. I was trying to work out why this wasn't how things were
> done already. FWIW, linux's lib
On Tue, 29 Oct 2002, John Polstra wrote:
> In article <[EMAIL PROTECTED]>,
> Doug Rabson <[EMAIL PROTECTED]> wrote:
> > On Tue, 29 Oct 2002, John Polstra wrote:
> > > When a symbol is defined in multiple libraries, the first library
> > > wins. That's how it has always been in Unix, for archive
In article <[EMAIL PROTECTED]>,
Doug Rabson <[EMAIL PROTECTED]> wrote:
> On Tue, 29 Oct 2002, John Polstra wrote:
> > When a symbol is defined in multiple libraries, the first library
> > wins. That's how it has always been in Unix, for archive libraries
> > and for shared libraries.
>
> This is
On Tue, 29 Oct 2002, John Polstra wrote:
> In article <[EMAIL PROTECTED]>,
> Doug Rabson <[EMAIL PROTECTED]> wrote:
> > I just spent a few hours trying to get gnome working on one of my systems,
> > since kde still appears to be completely hosed. Unfortunately, not much of
> > it worked reliably.
In article <[EMAIL PROTECTED]>,
Doug Rabson <[EMAIL PROTECTED]> wrote:
> I just spent a few hours trying to get gnome working on one of my systems,
> since kde still appears to be completely hosed. Unfortunately, not much of
> it worked reliably. In particular, all the sawfish preferences applets
I just spent a few hours trying to get gnome working on one of my systems,
since kde still appears to be completely hosed. Unfortunately, not much of
it worked reliably. In particular, all the sawfish preferences applets
crash instantly.
On investigating one of the crashes more carefully, I discov
75 matches
Mail list logo
