From owner-freebsd-stable@freebsd.org Sun Jan 29 17:36:56 2017 Return-Path: Delivered-To: freebsd-stable@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8B3BFCC7DB6; Sun, 29 Jan 2017 17:36:56 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5D098135B; Sun, 29 Jan 2017 17:36:56 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-241-75.lns20.per4.internode.on.net [121.45.241.75]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id v0THap9Y000435 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 29 Jan 2017 09:36:54 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: [IGNORE] ldd linker script /usr/lib/libc.so fail [IGNORE] To: freebsd-current , FreeBSD Stable References: <5278922c-a736-26ec-17a8-d9a1a684439e@freebsd.org> From: Julian Elischer Message-ID: <4439daf4-4173-110d-bd15-d144fed91ceb@freebsd.org> Date: Mon, 30 Jan 2017 01:36:45 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <5278922c-a736-26ec-17a8-d9a1a684439e@freebsd.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jan 2017 17:36:56 -0000 Tracked this down to a rogue copy of libc.so in an unexpected place which was being found earlier than the real one. On 30/1/17 1:13 am, Julian Elischer wrote: > Hi > > the linker script /usr/lib/libc.so fails when you are using the > --sysroot options because it > > contains absolute paths. > > > Does anyone know if there is a way to add the sysroot to the script? > > currently teh on ein our sysroot looks like: > > $ cat /usr/build/buildroot/tools/x86_FBSD1X_gcc4.2.4/usr/lib/libc.so > /* $FreeBSD$ */ > GROUP ( /lib/libc.so.7 /usr/lib/libc_nonshared.a > /usr/lib/libssp_nonshared.a ) > > but I'd like to do something like: > > GROUP ( ${sysroot}/lib/libc.so.7 ${sysroot}/usr/lib/libc_nonshared.a > ${sysroot}/usr/lib/libssp_nonshared.a ) > > but don't think I can do that > > from what I see below however it shouldn't be needed. > > Is this a bug in our version of ld? or am I misreading it? > > > I quote from one such source : > > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/4/html/Using_ld_the_GNU_Linker/simple-commands.html > > > ================================================ > INPUT(file, file, …), INPUT(file file …) > > The INPUT command directs the linker to include the named files in > the link, as though they were named on the command line. > > For example, if you always want to include subr.o any time you do > a link, but you can't be bothered to put it on every link command > line, then you can put INPUT (subr.o) in your linker script. > > In fact, if you like, you can list all of your input files in the > linker script, and then invoke the linker with nothing but a -T > option. > > In case a /sysroot prefix/ is configured, and the filename starts > with the / character, and the script being processed was located > inside the /sysroot prefix/, the filename will be looked for in > the /sysroot prefix/. Otherwise, the linker will try to open the > file in the current directory. If it is not found, the linker will > search through the archive library search path. See the > description of -L in Section 3.1 /Command Line Options/ > . > > > If you use INPUT (-lfile), ld will transform the name to > libfile.a, as with the command line argument -l. > > When you use the INPUT command in an implicit linker script, the > files will be included in the link at the point at which the > linker script file is included. This can affect archive searching. > > GROUP(file, file, …), GROUP(file file …) > > The GROUP command is like INPUT, except that the named files > should all be archives, and they are searched repeatedly until no > new undefined references are created. > > ========================================= > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe@freebsd.org" > >