From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16956 invoked by alias); 20 Jun 2006 12:24:17 -0000 Received: (qmail 16946 invoked by uid 22791); 20 Jun 2006 12:24:16 -0000 X-Spam-Check-By: sourceware.org Received: from mta08-winn.ispmail.ntl.com (HELO mtaout02-winn.ispmail.ntl.com) (81.103.221.48) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 20 Jun 2006 12:24:04 +0000 Received: from aamtaout01-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout02-winn.ispmail.ntl.com with ESMTP id <20060620122401.MYOD27023.mtaout02-winn.ispmail.ntl.com@aamtaout01-winn.ispmail.ntl.com> for ; Tue, 20 Jun 2006 13:24:01 +0100 Received: from merlin ([213.107.3.77]) by aamtaout01-winn.ispmail.ntl.com with ESMTP id <20060620122401.RENU19763.aamtaout01-winn.ispmail.ntl.com@merlin> for ; Tue, 20 Jun 2006 13:24:01 +0100 From: Michael Wetherell To: binutils@sourceware.org Subject: ld -m elf_i386 on x86 Solaris Date: Tue, 20 Jun 2006 12:33:00 -0000 User-Agent: KMail/1.7.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200606201323.58872.mike.wetherell@ntlworld.com> X-IsSubscribed: yes Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2006-06/txt/msg00300.txt.bz2 Hi, Using the elf_i386 emulation on x86 solaris, when linking to a shared library it doesn't search the DT_RPATH, etc. for other shared libaries the linked library depends on. I've put a suggested fix below, which uses targ_extra_libpath=elf_i386 instead of targ_extra_emuls=elf_i386: Index: ld/configure.tgt =================================================================== RCS file: /cvs/src/src/ld/configure.tgt,v retrieving revision 1.188 diff -u -r1.188 configure.tgt --- ld/configure.tgt 24 May 2006 07:36:11 -0000 1.188 +++ ld/configure.tgt 19 Jun 2006 21:44:39 -0000 @@ -162,11 +162,12 @@ tdir_elf_i386=`echo ${targ_alias} | sed -e 's/x86_64/i386/'` ;; i[3-7]86-*-sysv[45]*) targ_emul=elf_i386 ;; i[3-7]86-*-solaris2*) targ_emul=elf_i386_ldso - targ_extra_emuls="elf_i386 elf_x86_64" + targ_extra_libpath=elf_i386 + targ_extra_emuls=elf_x86_64 ;; i[3-7]86-*-unixware) targ_emul=elf_i386 ;; i[3-7]86-*-solaris*) targ_emul=elf_i386_ldso - targ_extra_emuls="elf_i386" + targ_extra_libpath=elf_i386 ;; i[3-7]86-*-netbsdelf* | \ i[3-7]86-*-netbsd*-gnu* | \ I came across the problem using gcc on Solaris 10, e.g.: $ echo "int main() { return 0; }" > foo.c $ gcc foo.c -lsocket /usr/local/bin/ld: warning: libnsl.so.1, needed by /usr/lib/libsocket.so, not found (try using -rpath or -rpath-link) 64-bit linking also isn't working, but that's something separate. 32-bit linking does work, so if gcc is configured with --disable-multilib then --with-gnu-ld will work. The problem shows up with gcc because it invokes ld as 'ld -m elf_i386'. See gcc/config/i386/sol2-10.h in the gcc sources: #define TARGET_LD_EMULATION "%{m64:-m elf_x86_64}%{!m64:-m elf_i386} " Should it be using the default emulation anyway? And should the same apply the 64-bit linking? If elf_i386_ldso is needed will an elf_x86_64_ldso be needed too? Regards, Mike