From owner-freebsd-amd64@FreeBSD.ORG Mon Jun 7 04:59:35 2004 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7FC4E16A4CE; Mon, 7 Jun 2004 04:59:35 +0000 (GMT) Received: from mail.mcneil.com (rrcs-west-24-199-45-54.biz.rr.com [24.199.45.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4157F43D46; Mon, 7 Jun 2004 04:59:35 +0000 (GMT) (envelope-from sean@mcneil.com) Received: from localhost (localhost.mcneil.com [127.0.0.1]) by mail.mcneil.com (Postfix) with ESMTP id 98B6AFD03B; Sun, 6 Jun 2004 21:59:30 -0700 (PDT) Received: from mail.mcneil.com ([127.0.0.1]) by localhost (server.mcneil.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 59128-07; Sun, 6 Jun 2004 21:59:30 -0700 (PDT) Received: from [24.199.45.54] (mcneil.com [24.199.45.54]) by mail.mcneil.com (Postfix) with ESMTP id DE74BFD020; Sun, 6 Jun 2004 21:59:29 -0700 (PDT) From: Sean McNeil To: Daniel Eischen In-Reply-To: References: Content-Type: text/plain Message-Id: <1086584369.7335.11.camel@server.mcneil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Sun, 06 Jun 2004 21:59:29 -0700 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mcneil.com cc: freebsd-amd64@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: more symbol binding problems X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jun 2004 04:59:35 -0000 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