From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31180 invoked by alias); 6 Jan 2018 19:58:24 -0000 Mailing-List: contact crossgcc-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: crossgcc-owner@sourceware.org Received: (qmail 31162 invoked by uid 89); 6 Jan 2018 19:58:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=H*r:JAMES, build-time, buildtime, H*F:D*att.net X-HELO: sonic306-24.consmr.mail.ne1.yahoo.com Received: from sonic306-24.consmr.mail.ne1.yahoo.com (HELO sonic306-24.consmr.mail.ne1.yahoo.com) (66.163.189.86) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 06 Jan 2018 19:58:22 +0000 Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.ne1.yahoo.com with HTTP; Sat, 6 Jan 2018 19:58:20 +0000 Received: from smtp103.sbc.mail.ne1.yahoo.com (EHLO [192.168.0.33]) ([98.138.84.214]) by smtp414.mail.ne1.yahoo.com (JAMES SMTP Server ) with ESMTPA ID 1cb071a1a4d4dfbf323728a8848be640 for ; Sat, 06 Jan 2018 19:58:16 +0000 (UTC) Subject: Re: binutils executables capture paths from build machine To: crossgcc@sourceware.org References: <20180106192755.GA3536@femur> From: Alexey Neyman Message-ID: Date: Sat, 06 Jan 2018 19:58:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20180106192755.GA3536@femur> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-01/txt/msg00001.txt.bz2 On 01/06/2018 11:27 AM, Steven Taschuk wrote: > Hi! I'm using crosstool-ng 1.23.0 to make a cross-native toolchain, > and am a bit confused about the configuration and install of the > binutils executables. > > I've understood correctly, the bash function do_binutils_for_host > configures binutils with --prefix=${CT_PREFIX_DIR} and installs the > executables with make install. This procedure results in paths from > the build machine being embedded in the binaries, in at least two > places: the use of BINDIR at binutils-2.28/bfd/plugin.c:337; and > the various uses of DEBUGDIR in binutils-2.28/bfd/dwarf2.c (where > DEBUGDIR=${libdir}/debug; see binutils-2.28/bfd/configure.ac:108). It is not just that. Also, NLS code embeds some build-time paths into the code, etc. The problem is that we don't know where the toolchain will be located and many configure scripts "automagically" find headers/libraries based on the value of $prefix. It may be possible to work this around by adding separate --with-foo=PATH options to each an every component's configure invocation. But this would be quite time consuming and hard to maintain (as the list of such options is likely to change from release to release). So strictly speaking, the toolchain is only guaranteed to work if it is later installed at the exact location of CT_PREFIX_DIR. In practice, it seems to work fine even if it is relocated (but I haven't tested features like LTO with "relocated" toolchain). For Canadian, the build-to-target cross toolchain is installed in a separate location inside a temporary directory; CT_PREFIX_DIR is used as the host toolchain (and should, therefore, match the path where the toolchain will be placed on the host - but again, in practice it doesn't seem to matter much). Regards, Alexey. > > I would have expected that, for a cross-native (or, for that matter, > Canadian) build, binutils would be configured with --prefix=/usr or > something, then installed with make DESTDIR=${CT_SYSROOT_DIR} install, > for later transfer to the host. That's what do_binutils_for_target > does, but it seems to build and install only libiberty and libbfd, > not the executables. > > For builds with build!=host, how should binutils executables be built? > > (Context: I'm developing a small reproducible and self-reproducing > Linux distribution, which requires making a reproducible cross-native > toolchain. I also think there are some similar issues in the gcc > executables, but haven't tracked those down yet.) >