From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12989 invoked by alias); 15 Dec 2004 14:40:07 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 12880 invoked from network); 15 Dec 2004 14:40:00 -0000 Received: from unknown (HELO fra-del-03.spheriq.net) (195.46.51.99) by sourceware.org with SMTP; 15 Dec 2004 14:40:00 -0000 Received: from fra-inc-01.spheriq.net (fra-inc-01.spheriq.net [195.46.51.65]) by fra-del-03.spheriq.net with ESMTP id iBFEdwgD027251 for ; Wed, 15 Dec 2004 14:39:58 GMT Received: from fra-out-01.spheriq.net (fra-out-01 [195.46.51.129]) by fra-inc-01.spheriq.net with ESMTP id iBFEdbiS022480 for ; Wed, 15 Dec 2004 14:39:41 GMT Received: from fra-cus-02.spheriq.net (fra-cus-02.spheriq.net [195.46.51.38]) by fra-out-01.spheriq.net with ESMTP id iBFEdWc1030219 for ; Wed, 15 Dec 2004 14:39:32 GMT Received: from beta.dmz-eu.st.com (beta.dmz-eu.st.com [164.129.1.35]) by fra-cus-02.spheriq.net with ESMTP id iBFEdTJT004383 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK) for ; Wed, 15 Dec 2004 14:39:31 GMT Received: from zeta.dmz-eu.st.com (ns2.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 30FDBDBDE for ; Wed, 15 Dec 2004 14:35:35 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 60012) id D20FF47369; Wed, 15 Dec 2004 14:35:24 +0000 (GMT) Received: from zeta.dmz-eu.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 9A55C75969 for ; Wed, 15 Dec 2004 14:35:24 +0000 (UTC) Received: from mail1.bri.st.com (mail1.bri.st.com [164.129.8.218]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 29E5847353 for ; Wed, 15 Dec 2004 14:35:24 +0000 (GMT) Received: from st.com (terrorhawk.bri.st.com [164.129.15.13]) by mail1.bri.st.com (MOS 3.4.4-GR) with ESMTP id AQD02438 (AUTH "andrew stubbs"); Wed, 15 Dec 2004 14:34:55 GMT Message-ID: <41C04BD6.E752FF3E@st.com> Date: Wed, 15 Dec 2004 14:40:00 -0000 From: Andrew STUBBS Organization: STMicroelectronics MIME-Version: 1.0 To: binutils Subject: Cross linking dynamic executables Content-Type: multipart/mixed; boundary="------------1E1EC2EF4E41552CA10CE374" X-O-Virus-Status: No X-O-URL-Status: Not Scanned X-O-CSpam-Status: Not Scanned X-O-Spam-Status: Not scanned X-O-Image-Status: Not Scanned X-O-Att-Status: No X-SpheriQ-Ver: 1.8.3 X-SW-Source: 2004-12/txt/msg00166.txt.bz2 This is a multi-part message in MIME format. --------------1E1EC2EF4E41552CA10CE374 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-length: 742 When cross compiling a dynamic executable, the linker attempts to find the dynamic linker in the 'standard places' (just as it does when compiling nativly). This behaviour is rather irritating when the linker tries to link an SH object file (in my case) against the x86 dynamic linker on the build system. I do not know whether my solution is acceptable to other people, but I have attached a patch which attempts to solve the problem. It makes much more sense to me that the linker should look for cross dynamic linkers in the same place it looks for cross dynamic libraries. If it does not find it with the libraries it still continues to look in the standard places. -- Andrew Stubbs andrew.stubbs@st.com (aka. andrew.stubbs@superh.com) --------------1E1EC2EF4E41552CA10CE374 Content-Type: text/plain; charset=us-ascii; name="cross-link.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="cross-link.patch" Content-length: 1095 2004-12-15 Andrew Stubbs * emultempl/elf32.em (gld*_after_open): Search for the dynamic linker in the library search path (as opposed to the 'standard' places) when cross compiling. --- src/ld/emultempl/elf32.em 2004-11-22 20:33:33.000000000 +0000 +++ src/ld/emultempl/elf32.em 2004-12-14 11:33:23.000000000 +0000 @@ -880,8 +880,20 @@ { char *filename; +EOF +if [ "x${host}" = "x${target}" ] ; then +# When cross compiling the dynamic linker is unlikly to be in +# the standard place - especially if the binutils were built and +# then moved to somewhere else. In this case the best thing to do +# is look for the dynamic linker in the same place as the libraries. +# If compiling natively ignore the -L options on the command line +# and always used the normal places. +cat >>e${EMULATION_NAME}.c <cmdline) continue; +EOF +fi +cat >>e${EMULATION_NAME}.c <name) + len + 2); sprintf (filename, "%s/%s", search->name, l->name); nn.name = filename; --------------1E1EC2EF4E41552CA10CE374--