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