|Sean McNeil||Jun 6, 2004 4:28 pm|
|Daniel Eischen||Jun 6, 2004 5:25 pm|
|Sean McNeil||Jun 6, 2004 5:43 pm|
|Daniel Eischen||Jun 7, 2004 3:52 am|
|Daniel Eischen||Jun 7, 2004 3:56 am|
|Sean McNeil||Jun 7, 2004 4:06 am|
|Daniel Eischen||Jun 7, 2004 4:37 am|
|Sean McNeil||Jun 7, 2004 4:59 am|
|Daniel Eischen||Jun 7, 2004 5:30 am|
|Sean McNeil||Jun 7, 2004 10:18 am|
|Daniel Eischen||Jun 7, 2004 1:25 pm|
|Sean McNeil||Jun 7, 2004 4:30 pm|
|Daniel Eischen||Jun 7, 2004 5:00 pm|
|Sean McNeil||Jun 7, 2004 5:15 pm|
|Subject:||more symbol binding problems|
|From:||Sean McNeil (se...@mcneil.com)|
|Date:||Jun 7, 2004 4:59:18 am|
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?
/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?