more symbol binding problems

[Sean McNeil]

On Sun, 2004-06-06 at 22:30, Daniel Eischen wrote:
> 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.

I'm sorry, but I have rebuilt everything on this machine from i386 to
amd64 so I do not have the older binaries to show the same dependency. 
Unless something odd happened between the following:

1) working i386.
2) build world build/install kernel with a target arch amd64
3) cp ld-elf.so.1 to ld-elf32.so.1, reboot, install world
4) portupgrade -af

then the dependencies should be identical between i386 and amd64.

> > 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.

There is no nss_ldap problem.  nss_ldap worked perfectly on i386.  It
causes issues on amd64 because of a problem in threads.

> > 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.

> 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.

> 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.

So I think we agree that thread-safe libraries should not link with
-lpthread if they do not call thread-specific routines.

> This should be solved by fixing the ports appropriately.
> For a), it can be done by using PTHREAD_LIBS=-pthread.