Date: Mon, 7 Jun 2004 01:30:53 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Sean McNeil <sean@mcneil.com> Cc: freebsd-threads@freebsd.org Subject: Re: more symbol binding problems Message-ID: <Pine.GSO.4.10.10406070104030.25220-100000@pcnet5.pcnet.com> In-Reply-To: <1086584369.7335.11.camel@server.mcneil.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 6 Jun 2004, Sean McNeil wrote:
> On Sun, 2004-06-06 at 21:37, Daniel Eischen wrote:
> >
> > Libc is the second library on the list, so any attempt to dlopen()
> > a library that needs libc_r (or even libpthread) isn't going to
> > work correctly.
> >
> > I think basically all your problems are the result of things
> > being linked (ld) improperly. If the executable is going to
> > dlopen() a library that requires the threads library, then
> > the executable must explicitly link to the threads libary.
> > I said before, if you set CFLAGS=-pthread, it will avoid
> > linking to libpthread when building shared libraries.
>
> That is very interesting. This works perfectly for i386 and always
> has. There is a fundamental difference here that is going to cause all
> sorts of issues with ports and programs. Essentially, there is no
> reason why this should not work. It works for Linux, it works for
> FreeBSD/x86, why not FreeBSD/amd64?
Show me the same exact shared library dependencies under x86.
> You may be 10000% correct in principle, I don't know. I personally
> think that this should not be the case. Anyone should be able to create
> loadable extensions to a program that may do threading of some sort and
> not require the starting application to be linked with the thread
> library. Principle is all well and good, but we why enforce something
> that doesn't need to be? Why can't freebsd/amd64 behave nice like
> freebsd/i386.
It doesn't work under i386 either. Remember the nss_ldap
problem? That was exactly the same and on i386.
> Let me make reiterate.... I am using a system that I converted from
> i386 to amd64. Everything (all the ports) were working without any
> problems whatsoever. These are the same exact ports that I convert over
> to amd64. If it is not legal to do things like this then why do these
> exact same ports work perfectly fine with freebsd/i386?
>
> Your analysis and assistance with this has been invaluable so far, but I
> don't want this to just be dismissed because in principle it doesn't
> need to be supported. IMHO, amd64 should work just like i386. Since it
> works with i386, shouldn't we make it work for amd64?
There is no difference. It isn't going to work on i386 either.
Once you load the threads library, the libc locking functions
will be overloaded with the locking functions in libpthread.
When libpthread is unloaded, libc locking functions still point
to the now non-existent library. If something tries to use
a lock, fall down go boom.
There's also the problem of overloaded functions and cancellation
points. These won't work correctly because of ordering. It's
like trying to use '-lc -lpthread' to link an application.
That isn't going to work; you need '-lpthread -lc'.
There are two reasons for a library to use the threads library.
a) It uses threading functions for thread safety; or
b) It creates threads behind the scenes (for instance
if there were a libaio).
For a), it needn't link to the threads library because all
the necessary locking functions are in libc. If an application
is threaded, then the threads library will be pulled in (along
with the locking functions) because the _application_ will
be linked to the threads library. For b), we mandate that
the application always be linked with the threads library
because the library needs threads.
This should be solved by fixing the ports appropriately.
For a), it can be done by using PTHREAD_LIBS=-pthread.
--
Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10406070104030.25220-100000>