From owner-freebsd-toolchain@freebsd.org Sun Oct 29 07:51:04 2017 Return-Path: Delivered-To: freebsd-toolchain@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 A5F74E5C9C6; Sun, 29 Oct 2017 07:51:04 +0000 (UTC) (envelope-from eddy.petrisor@gmail.com) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 39914700EB; Sun, 29 Oct 2017 07:51:04 +0000 (UTC) (envelope-from eddy.petrisor@gmail.com) Received: by mail-wm0-x22e.google.com with SMTP id r196so10514817wmf.2; Sun, 29 Oct 2017 00:51:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Lb6cPrku288FjcWMmeUpT0wLTfcsWbHkOepvE3ZJZ+8=; b=aHhjp0y9UF2G5anvlSIGXeSBBgA/f2Ji2AAMy//gPCyb5OrKZy+Y/qkITQIjvT9h7c WTIgEQJaQVCiDIVKZQ1VMUOHhcNMc2rD7ghbP/l/GCTZDL0GCphdokbFNO4Q0tTqhh2l FaGRGc4dKF7Zncxxthkbn7PxLNzykCrf4barBHZ1mt/IFoR6g444gYgFA7Do9VN44BeL hMJhdtigjZEGLgMzvw7oNyvPImq2FPIHJPi/BvEl/NYyxS+U14LG9p57/1rf5N29it13 sdNAzAr1U+TDxdEVGCAU6SoBWYUT5Dq9zmyoyZx48+Xqj++PcIQvSW6PQ0zD7G9uVh7y dWOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Lb6cPrku288FjcWMmeUpT0wLTfcsWbHkOepvE3ZJZ+8=; b=fC4gW7Og3pX4uqANvu2GmPYZ/5aV0ju2F5GOfp7XKqTsX3wx+C3ph6UooMVy8QpFnI 4A17UxNwlcq17xgqvVggfB9R52OfPmJL4Rx5SX3b9tyDqh2f0S4lGPEqsYRmp10BCEhC ZimVA4wDxbwvgLHXEEXUGftnpQlL40XsSBxqcJUBL2h6LKxZpojuGGHGrS8Fvl96bIPK QsCcvZn9zvYiLESfOkGP2eA5BF8p25FUgeffqQ2st6PuW74Fz9MpvABJhxO5BOZ/ZWyq BcgcbllY9RgAjwopR4m/u2fmTUAWH0Ns2hbuXl9xuJ/RtwR7dTnpi9j+VrQ5Jo2r8Ace Kt1Q== X-Gm-Message-State: AMCzsaX6WDSolEb3h1guSPpFhuCVovVJon/5lfb/xgL+4Y1MhwY0zjmx lMeVfWuGi5HdGJ5t2guBUc4EwLmk/8/+6rRWGaoD7s0n X-Google-Smtp-Source: ABhQp+RETvaIEKM2x8EM6kb6yv+IVX2+VvXXeUC9sUQfGMbs8t5Jl984GZkjFpMmT1t5oOnRmcJYV2684XQC9SRuw4U= X-Received: by 10.28.111.203 with SMTP id c72mr997561wmi.42.1509263461837; Sun, 29 Oct 2017 00:51:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.173.129 with HTTP; Sun, 29 Oct 2017 00:51:01 -0700 (PDT) In-Reply-To: <7CAFD8CC-BDA1-4E89-BD7E-D0089E27036F@dsl-only.net> References: <7CAFD8CC-BDA1-4E89-BD7E-D0089E27036F@dsl-only.net> From: =?UTF-8?Q?Eddy_Petri=C8=99or?= Date: Sun, 29 Oct 2017 09:51:01 +0200 Message-ID: Subject: Re: lib/clan/llvm.build.mk: Shouldn't BUILD_TRIPLE definition rely host 'cc -dumpmachine'? To: Mark Millard Cc: Dimitry Andric , freebsd-arm@freebsd.org, FreeBSD Toolchain Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Oct 2017 07:51:04 -0000 Pe 28 oct. 2017 5:31 PM, "Mark Millard" a scris: On 2017-Oct-28, at 4:11 AM, Dimitry Andric wrote: > On 27 Oct 2017, at 08:23, Eddy Petri=C8=99or wrote: >> >> I am trying to make the FreeBSD code base build from a Linux host and >> found this bit which defines BUILD_TRIPLE in a way which to my >> untrained eyes look like overengineering. >> BUILD_TRIPLE?=3D >> ${BUILD_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION} > > I don't see much overengineering here? :) We simply trust BUILD_ARCH, > as it is passed in by the top-level Makefile.inc1. This is how most of > these down-level Makefiles work. Running all kinds of commands to > figure out architectures and the like should be avoided in such > Makefiles. I understand. The stage I am at is building a cross compiler for x86_64 Linux host and whatever TARGET was chosen through TARGET and TARGET_ARCH. >> To support a Linux host I made these changes that is using 'cc >> -dumpmachine' to get the correct BUILD_TRIPLE, > > Unfortunately, this is the wrong option to do so. The gcc manual says: > > -dumpmachine > Print the compiler=E2=80=99s target machine (for example, =E2=80=98i686-= pc-linux-gnu=E2=80=99) > -and don=E2=80=99t do anything else. Since my intention is to use the *host cc* to define the BUILD_TRIPLE on non-FreeBSD systems, this is exactly what I wanted to accomplish so the llvm/clang build will have the correct build triple for the foreign OS in LLVM_HOST_TRIPLE, just 3 lines lower than the BUILD_TRIPLE definition. Yep --and it is even more complicated: gcc vs. clang are sometimes different for the target listed. . . For example -m32 for amd64 changes the clang result: # clang -dumpmachine x86_64-unknown-freebsd12.0 .. # gcc7 -dumpmachine x86_64-portbld-freebsd12.0 Hmm, from these examples and the different vendor part, the answer for a BSD host compiler is clearly no. I also found it strange that the ABI part is forced to 'freebsd12.0' no matter if the host FreeBSD is head or older (e.g. 10.x or 11.x). I assume this correct because the legacy stage makes sure the compatibility shims are in place, correct? For non-FreeBSD host, the vendor part looks like will need to be forced to 'unknown' for my idea to work more reliably. > E.g, it prints the *target* tripe, not the build triple. My guess is that Eddy was depending on plain cc being a "self hosting" (target=3Dbuild) type of compiler command in his intended environment(s). 100% correct. This is trying to address the fact that using the OS_VERSION=3Dfreebsd12.0 defintion to define the host compiler ABI makes no sense for non-FreeBSD hosts, since the appropriate host ABI definitio could be 'linux-gnu', 'linux-gneabi', 'darwin11*' etc. Various linux distributions patch uname and its -p code (for example). Even for the same kernel being in use, giving different textual results. -m seemed more stable in my limited testing. Everyplace that uses uname probably needs to be reviewed for a possible re-work. BUILD_ARCH and its use is an example. Yes, I have some places where I made MACHINE* related changes, and a wrapper script to enforce some things to be correct for the Linux-host--FreeBSD-target scenario. See this wrapper, for example: https://github.com/eddyp/freebsd/blob/linux-fixes/Linux.sh >> but I am wondering if >> it shouldn't be OK for building on a FreeBSD host >> >> +BUILD_OS!=3D uname -s >> + > > Again, this should be set by the top-level Makefiles, not in this one. I am aware of that. For the purpose of focusing the thread on the 'is the host cc dumpmachine better at definig BUILD_TRIPLET' topic, I prefered to present code only with local modifications. My actual code is doing things like these: https://github.com/eddyp/freebsd/commit/caf7995fac43453f4f84 3cb15d1696283e12b783 >> What do you think, should the code be instead: [..] >> ${TARGET_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${ OS_VERSION}${TARGET_ABI} >> +HOST_CC_DUMPMACHINE!=3D cc -dumpmachine >> +BUILD_TRIPLE?=3D ${HOST_CC_DUMPMACHINE} > > No, this is definitely incorrect, as stated above. It certainly would not be appropriate for general use on FreeBSD: more of a local workaround for an odd context, not a general solution. Assuming 'odd context=3DLinux host', would you see something wrong, except the need to overwrite the vendor part to 'unknown', if it exists? For instance on Debian/Ubuntu amd64 I have: eddy@feodora:~ $ uname -m ; uname -p ; uname -s ; uname -o ; uname -r x86_64 x86_64 Linux GNU/Linux 4.4.0-96-generic eddy@feodora:~ $ cc -dumpmachine x86_64-linux-gnu eddy@feodora:~$ cc --version cc (Ubuntu 5.4.0-6ubuntu1~16.04.5) 5.4.0 20160609 Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. And cc is actually pointing though the debian-alternatives mechanisms to gcc. eddy@feodora:~/usr/src/FreeBSD/freebsd$ ll `which cc` lrwxrwxrwx 1 root root 20 mar 1 2016 /usr/bin/cc -> /etc/alternatives/cc* eddy@feodora:~/usr/src/FreeBSD/freebsd$ ll /etc/alternatives/cc lrwxrwxrwx 1 root root 12 mar 1 2016 /etc/alternatives/cc -> /usr/bin/gcc= * Eddy