Date: Mon, 7 Jun 2004 09:25:31 -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.10406070918340.6934-100000@pcnet5.pcnet.com> In-Reply-To: <1086603496.7335.29.camel@server.mcneil.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 7 Jun 2004, Sean McNeil wrote: > On Sun, 2004-06-06 at 22:30, Daniel Eischen wrote: > > > > It doesn't work under i386 either. Remember the nss_ldap > > problem? That was exactly the same and on i386. > > There is no nss_ldap problem. nss_ldap worked perfectly on i386. It > causes issues on amd64 because of a problem in threads. Yes, there was. See the archives (I forget if it was -current or -threads). I believe the resolver functions in libc were changed to work around it. > > > 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. > > It worked on i386. None of the cases mentioned before unload the thread > library until an atexit. I thought they were automatically unloaded when the library was unloaded. That was the problem with nss_ldap. > > 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'. > > As far as I know, this works. At least for Linux and it should for > FreeBSD. The ordering doesn't matter because the overloaded routines > are actually weak references in libc and strong references in pthread. > So pthread symbols win. It doesn't work here and I don't believe ever has since libc_r was split from libc.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10406070918340.6934-100000>