more symbol binding problems

[Sean McNeil]

On Sun, 2004-06-06 at 21:37, Daniel Eischen wrote:
> On Sun, 6 Jun 2004, Sean McNeil wrote:
> 
> > On Sun, 2004-06-06 at 20:56, Daniel Eischen wrote:
> > > You really want to look at the executable (httpd?) too.  What
> > > does 'ldd' on it show?
> > 
> > Hmmm...
> > 
> > /usr/local/sbin/httpd:
> >         libz.so.2 => /lib/libz.so.2 (0x200675000)
> >         libssl.so.3 => /usr/local/lib/libssl.so.3 (0x200784000)
> >         libcrypto.so.3 => /usr/local/lib/libcrypto.so.3 (0x2008be000)
> >         libaprutil-0.so.9 => /usr/local/lib/apache2/libaprutil-0.so.9
> > (0x200b12000)
> >         libldap.so.2 => /usr/local/lib/libldap.so.2 (0x200c28000)
> >         liblber.so.2 => /usr/local/lib/liblber.so.2 (0x200d60000)
> >         libdb41.so.1 => /usr/local/lib/libdb41.so.1 (0x200e6e000)
> >         libexpat.so.5 => /usr/local/lib/libexpat.so.5 (0x20102b000)
> >         libapr-0.so.9 => /usr/local/lib/apache2/libapr-0.so.9
> > (0x20114e000)
> >         libm.so.2 => /lib/libm.so.2 (0x201270000)
> >         libcrypt.so.2 => /lib/libcrypt.so.2 (0x201391000)
> >         libc.so.5 => /lib/libc.so.5 (0x2014ab000)
> >         libsasl2.so.2 => /usr/local/lib/libsasl2.so.2 (0x2016a9000)
> > 
> > So it looks like it is pulling in the ldap library without
> > pthreads/libc_r first.  So I think what is happening is that the symbols
> > resolved with ldap aren't updated when it is part of the DAG of php4. 
> > Not sure why these would get resolved so early.  I should think they are
> > lazy and happen a lot later.  But perhaps that is the bug?  Are lazy
> > resolutions failing to take into account the threading library needs
> > from dlopen'ing php4?
> 
> 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?

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.

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?

Sean