Date: Thu, 31 Oct 2002 09:22:13 -0500 (EST) From: Daniel Eischen <eischen@pcnet1.pcnet.com> To: Doug Rabson <dfr@nlsystems.com> Cc: Alexander Kabaev <ak03@gte.com>, Terry Lambert <tlambert2@mindspring.com>, current@FreeBSD.ORG Subject: Re: [PATCH: libc]Re: gnome on current Message-ID: <Pine.GSO.4.10.10210310910260.27891-100000@pcnet1.pcnet.com> In-Reply-To: <20021031085946.N22480-100000@herring.nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <tlambert2@mindspring.com> 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 search is defined to be depth-first.
> > >
> > > You are ignoring the fact, that objects, loaded at the application startup
> > > time are getting searched first, followed RTLD_GLOBAL objects, and finally by
> > > the loaded object DAG. LD_PRELOAD objects override them all.
> > >
> > > >
> > > > First strong/last weak should win. You are saying "last weak" is not
> > > > winning. That's a linker bug.
> > >
> > > 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.
> >
> > I disagree. See Solaris 6, 7, 8 & 9 for an example.
>
> Actually, I don't much care about Solaris. I care that a popular desktop
> package which we have supported for earlier releases does not work. I
> don't expect anyone to ever run gnome on Solaris but people certainly run
> gnome on FreeBSD.
Umm, isn't GNOME going to be Solaris' window toolkit. Sun said this
months ago, upsetting some of the KDE folks.
Have you looked at how libgcc uses pthread routines? It doesn't
have a problem.
Basically, it wraps all the pthread functions which could be done
something like this:
--
Dan Eischen
%%% libxthr.h %%%
#ifndef _LIBXTHR_H_
#define _LIBXTHR_H_
#include <pthread.h>
int xthr_isthreaded(void);
int xthr_mutex_lock(pthread_mutex_t *);
int xthr_mutex_unlock(pthread_mutex_t *);
#endif
%%%
%%% libxthr.c %%%
#include <unistd.h>
#include <stdlib.h>
#include "libxthr.h"
#pragma weak pthread_create;
#pragma weak pthread_mutex_lock;
#pragma weak pthread_mutex_unlock;
static void *pthread_create_addr = (void *)&pthread_create;
int
xthr_isthreaded(void)
{
return (pthread_create_addr != NULL);
}
int
xthr_mutex_lock(pthread_mutex_t *mutex);
{
if (xthr_isthreaded())
return (pthread_mutex_lock(mutex));
else
return (0);
}
int
xthr_mutex_unlock(pthread_mutex_t *mutex);
{
if (xthr_isthreaded())
return (pthread_mutex_unlock(mutex));
else
return (0);
}
%%%
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10210310910260.27891-100000>