more symbol binding problems
Daniel Eischen
eischen at vigrid.com
Mon Jun 7 13:25:35 GMT 2004
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.
More information about the freebsd-amd64
mailing list