From owner-freebsd-toolchain@freebsd.org Sun Apr 1 12:19:35 2018 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7C6DBF9161F for ; Sun, 1 Apr 2018 12:19:35 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 18CD368560; Sun, 1 Apr 2018 12:19:35 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from router.digiware.nl (localhost.digiware.nl [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id DF5822E39C; Sun, 1 Apr 2018 14:19:32 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.com Received: from smtp.digiware.nl ([127.0.0.1]) by router.digiware.nl (router.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cgI6z3M-vf_7; Sun, 1 Apr 2018 14:19:32 +0200 (CEST) Received: from [192.168.11.152] (unknown [192.168.11.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 436672E39A; Sun, 1 Apr 2018 14:19:32 +0200 (CEST) To: FreeBSD Toolchain , Dimitry Andric From: Willem Jan Withagen Subject: Looking for std::map::merge when compiling for Clang... Message-ID: <7f0f0f04-7073-ba49-526d-82330b1d0842@digiware.nl> Date: Sun, 1 Apr 2018 14:19:30 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.25 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, 01 Apr 2018 12:19:35 -0000 Hi, I'm trying to compile a src file with Ceph that has been upgrade to use more of the C++17 features, but it fails on a missing function: /home/jenkins/workspace/ceph-master/src/mds/OpenFileTable.cc:349:26: error: no member named 'merge' in 'std::__1::map, ceph::buffer::list, std::__1::less >, std::__1::allocator, ceph::buffer::list> > >' ctl.journaled_update.merge(ctl.to_update); ~~~~~~~~~~~~~~~~~~~~ ^ The actual code looks like: ==== ctl.journaled_update.merge(ctl.to_update); //ctl.journaled_update.insert(ctl.to_update.begin(), ctl.to_update.end()); // ctl.journaled_remove.merge(ctl.to_remove); ctl.journaled_remove.insert(ctl.to_remove.begin(), ctl.to_remove.end()); ==== The first "merge" fails, but the second (old code) works. It does compile on Linux/GCC, so probably there is a wrong/missing include, given the error. But which one??? included are: #include #include #include #include #include #include Suggestions? Thanx, --WjW From owner-freebsd-toolchain@freebsd.org Sun Apr 1 18:44:12 2018 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5792EF73F0F for ; Sun, 1 Apr 2018 18:44:12 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic307-3.consmr.mail.bf2.yahoo.com (sonic307-3.consmr.mail.bf2.yahoo.com [74.6.134.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E46F07886C for ; Sun, 1 Apr 2018 18:44:11 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: qA49C_oVM1kz7EoepKysBQBFbGjYNAsz7tkFdaTkTnykQNo.V2at8JWSrBOOKFW ysdTaDH4ZZVrIKztukU8wdRWs1K0QeWh.rYm9UP0364vfZ5zyM022vitLyZ0W_xQR0_lPTx95g7R mhh7AeeFGnUhGpUKzjqYVvIbRircuoB2cu7KdUq7FNTGUtK84ltoYV7f5Ew65e7_8qO_uWY5OfQG ANT0Gvgn.MmCKkm.lfcbseUjlImrMeg69m28GkvTsFs6QJJ0_hWj1viXtBT9QZ.25C8NT4I2akwf iozvdf0YBw1__DOCLJWfwFxaLIvbZEW_T7hkhXgnyqLawln38gVEJbR3IC0PW2ot8pAQotd4QtsM uk1uepxWI71OdYKnlDkv_5gmv_5.QrNJtTtQ_Dkboq1WSzk_yo0KWEMYuTedJLZcKfDzThbVIE6x 3R10.2puJhzivYTX8Fvzt38FlrRgstmsE7KLcxeY0Wg2VcKSohWhwBJk3r2JLYmx1GNUuVVVmNTG 59G.F4mnKQT.BCafFMQnTa8dmFvb7cANjB21qTA-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.bf2.yahoo.com with HTTP; Sun, 1 Apr 2018 18:44:04 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp424.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 1b85a55ceeace52a196075af82115a4e; Sun, 01 Apr 2018 18:44:03 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Subject: Re: Looking for std::map::merge when compiling for Clang... Message-Id: Date: Sun, 1 Apr 2018 11:44:01 -0700 To: wjw@digiware.nl, freebsd-toolchain@freebsd.org X-Mailer: Apple Mail (2.3445.6.18) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.25 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, 01 Apr 2018 18:44:12 -0000 Willem Jan Withagen wjw at digiware.nl wrote on Sun Apr 1 12:19:35 UTC 2018 : > I'm trying to compile a src file with Ceph that has been upgrade to use > more of the C++17 features, but it fails on a missing function: > > /home/jenkins/workspace/ceph-master/src/mds/OpenFileTable.cc:349:26: > error: no member named 'merge' in > 'std::__1::map, ceph::buffer::list, > std::__1::less >, > std::__1::allocator, > ceph::buffer::list> > >' > ctl.journaled_update.merge(ctl.to_update); > ~~~~~~~~~~~~~~~~~~~~ ^ If you can get ahold of the text for the compile command, it would be a good idea to send that out as additional information. A point about clang as a standard in FreeBSD, with the system and ports there are many alternatives. (Although having some level of C++17 support does cut down the size of the list.) In a C++17 context: #include should have defined merge for std::map. The error message suggests complete lack of a definition, rather than an unsupported type of argument (overload mismatch) or other such. Such might be because the compile did not indicate to use C++17 --or some other point that is outside OpenFileTable.cc . See the command that generated the error would likely help with identifying the proper context for fixing the issue. === Mark Millard marklmi26-fbsd at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-toolchain@freebsd.org Sun Apr 1 19:35:08 2018 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5D1E4F76BA7 for ; Sun, 1 Apr 2018 19:35:08 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F16717A364 for ; Sun, 1 Apr 2018 19:35:07 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from router.digiware.nl (localhost.digiware.nl [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 9E2AF2EE13; Sun, 1 Apr 2018 21:35:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at digiware.com Received: from smtp.digiware.nl ([127.0.0.1]) by router.digiware.nl (router.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZF3QGJmXNc72; Sun, 1 Apr 2018 21:35:04 +0200 (CEST) Received: from [192.168.11.152] (unknown [192.168.11.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 0B77A2EDF5; Sun, 1 Apr 2018 21:35:04 +0200 (CEST) Subject: Re: Looking for std::map::merge when compiling for Clang... To: Mark Millard , freebsd-toolchain@freebsd.org References: From: Willem Jan Withagen Message-ID: <9b2ab40b-7100-7c5b-34c2-0818cb85b692@digiware.nl> Date: Sun, 1 Apr 2018 21:35:02 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.25 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, 01 Apr 2018 19:35:08 -0000 On 01/04/2018 20:44, Mark Millard wrote: > Willem Jan Withagen wjw at digiware.nl wrote on > Sun Apr 1 12:19:35 UTC 2018 : > >> I'm trying to compile a src file with Ceph that has been upgrade to use >> more of the C++17 features, but it fails on a missing function: >> >> /home/jenkins/workspace/ceph-master/src/mds/OpenFileTable.cc:349:26: >> error: no member named 'merge' in >> 'std::__1::map, ceph::buffer::list, >> std::__1::less >, >> std::__1::allocator, >> ceph::buffer::list> > >' >> ctl.journaled_update.merge(ctl.to_update); >> ~~~~~~~~~~~~~~~~~~~~ ^ > > If you can get ahold of the text for the compile command, it would > be a good idea to send that out as additional information. > > A point about clang as a standard in FreeBSD, with the system and > ports there are many alternatives. (Although having some level of > C++17 support does cut down the size of the list.) > > In a C++17 context: > > #include > > should have defined merge for std::map. The error message suggests > complete lack of a definition, rather than an unsupported type of > argument (overload mismatch) or other such. > > Such might be because the compile did not indicate to use C++17 > --or some other point that is outside OpenFileTable.cc . See the > command that generated the error would likely help with > identifying the proper context for fixing the issue. One of the ceph codevelopers found the cause: libc++ still does not support "Splicing Maps and Sets", see https://libcxx.llvm.org/cxx1z_status.html , search for "p0083r3" . So the solution has to come from upstream. --WjW From owner-freebsd-toolchain@freebsd.org Tue Apr 3 20:32:11 2018 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8AB43F7E02C for ; Tue, 3 Apr 2018 20:32:11 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3A51972123 for ; Tue, 3 Apr 2018 20:32:11 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id 1BAE15A9F16; Tue, 3 Apr 2018 20:32:10 +0000 (UTC) Date: Tue, 3 Apr 2018 20:32:10 +0000 From: Brooks Davis To: freebsd-toolchain@freebsd.org Cc: Ali Mashtizadeh Subject: splitting libc -> libc + libsys and static linking Message-ID: <20180403203210.GA23045@spindle.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cWoXeonUoKmBZSoM" Content-Disposition: inline User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 20:32:11 -0000 --cWoXeonUoKmBZSoM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline We (mostly Ali) are working on a patch to to split the actual syscalls (__sys_) out of libc and into a libsys. For dynamic linking, this is fairly straightforward (link libc against libsys, maybe as a filter). For static linking, I'm looking for feedback on the right approach. Do we link libsys.a into libc.a? Do we try to teach all the compilers to add -lsys? I'm pretty sure we don't modify all the ports that statically link programs. Is there some easy approach I'm missing? -- Brooks --cWoXeonUoKmBZSoM Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJaw+TJAAoJEKzQXbSebgfAuhMIAI8tXIYqhheldGh7ol33Zaar dJUyK49eWVTrfJsaQxsFA3252tug+1uv91eXVgSayIZmYPxBFI0qFst+WGAOKB/7 B+pLdx6X6C+AfXAFS5FtTGtNmEoDHauxEXfZMuTtnj69a1jua+w5lgw2DSYCfEt1 5hc35NGSqpbqx0SmYflU/pmxh0+73qFnnIqT1EzyiFMsQmMnfvzraVLfTfWUzItH DLDwDDHbCdN0Dd4YGySeZc3ZAFKVvkWX6kLfqSt63f8lwNry/HKVTOor0RfDTKbv XBPueuGTCQ6uYUXnA4812Rtn1vYM1ppOLm7/KGf2T+huAV4HA8Fu0j4ZKBwoigQ= =WQxq -----END PGP SIGNATURE----- --cWoXeonUoKmBZSoM-- From owner-freebsd-toolchain@freebsd.org Tue Apr 3 20:39:47 2018 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EEB09F7E740 for ; Tue, 3 Apr 2018 20:39:46 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8AA31726C6 for ; Tue, 3 Apr 2018 20:39:46 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from coleburn.home.andric.com (coleburn.home.andric.com [192.168.0.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id BE4063FAAB; Tue, 3 Apr 2018 22:39:44 +0200 (CEST) From: Dimitry Andric Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_56106A58-63DD-4D38-BC75-13A0C1F29CFA"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: splitting libc -> libc + libsys and static linking Date: Tue, 3 Apr 2018 22:39:44 +0200 In-Reply-To: <20180403203210.GA23045@spindle.one-eyed-alien.net> Cc: freebsd-toolchain@freebsd.org, Ali Mashtizadeh To: Brooks Davis References: <20180403203210.GA23045@spindle.one-eyed-alien.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 20:39:47 -0000 --Apple-Mail=_56106A58-63DD-4D38-BC75-13A0C1F29CFA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 3 Apr 2018, at 22:32, Brooks Davis wrote: >=20 > We (mostly Ali) are working on a patch to to split the actual syscalls > (__sys_) out of libc and into a libsys. For dynamic linking, > this is fairly straightforward (link libc against libsys, maybe as a > filter). For static linking, I'm looking for feedback on the right > approach. Do we link libsys.a into libc.a? Do we try to teach all = the > compilers to add -lsys? I'm pretty sure we don't modify all the ports > that statically link programs. Is there some easy approach I'm = missing? The approach chosen for e.g. libc++ (and before that, libstdc++), was to put all needed objects from the dependent libs in the same .a file. See: = https://svnweb.freebsd.org/base/head/lib/libc%2B%2B/Makefile?revision=3D32= 1369&view=3Dmarkup#l61 and: = https://svnweb.freebsd.org/base/head/gnu/lib/libstdc%2B%2B/Makefile?revisi= on=3D315175&view=3Dmarkup#l57 For dynamic linking, you could use your approach of putting libsys in the NEEDED section, or add it to the libc.so linker script, like what is done for libc++.so. -Dimitry --Apple-Mail=_56106A58-63DD-4D38-BC75-13A0C1F29CFA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCWsPmkAAKCRCwXqMKLiCW ow+qAJ9PzuLj6du9JiO8vr4H0JUh2H4u5QCg36UrkMnV/LiuaOQMGUL1mQotNFs= =XCPQ -----END PGP SIGNATURE----- --Apple-Mail=_56106A58-63DD-4D38-BC75-13A0C1F29CFA-- From owner-freebsd-toolchain@freebsd.org Tue Apr 3 20:44:24 2018 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 374C6F7ED91 for ; Tue, 3 Apr 2018 20:44:24 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (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 AD07472F3B for ; Tue, 3 Apr 2018 20:44:23 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-wm0-x242.google.com with SMTP id r82so38033572wme.0 for ; Tue, 03 Apr 2018 13:44:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=ygm+xUKafvyhS8kIQOYht+UqcON4i7Pxgc5sJXnQAaM=; b=T93rjxv4XY3Bq+C2iz0KrGC+PP6twHrpq9sQuXYifIEFlyM7+wdthGTIk1IIfUFS8N 8gXmi5wsbZTlBxa75ez0Eo4PVnNS5xRfXYGcxN9++ZkAz0cOY7cg3NoxGbviDtbqrI2K yCOwEYCDsiVjwLk4eUlMqqwn2cp6Iuiyl4/DYDZPNYjxtN3CJp2MBLGzXQVJD9gY03EY uqiYwvOlYtWa3T6V3rJb7X0YwIbp3lQEhme+oGrBniA1nyrpeYSVfLu56nTCaBAXk+xS 0CZMZn8EKFUL16s4/Z3UFcY/iD2SoLQEgNv/x5KYoWzGaqICQIZf3bo3WMr8qz0OmRsv g6Qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=ygm+xUKafvyhS8kIQOYht+UqcON4i7Pxgc5sJXnQAaM=; b=YQox5F2Yda3c8YY4iQkAIBjPNAnqCj30NWWdpRVoZUlpmU1SdHVO59I+wzW6iB2rDe RBvWjIJG0VHFync5s5cqqZloPKxSrDENRCQslidztLiTuyIBN2SqYuRuuI+rJ7fEQHTT J61g6yhKlty4XNqgHwN652tA84B23W3jRz5xYRV/c1MrBd720kOldB6PJq/pNP8WjwCb WonOgU3f2wwfkw+wzdg7jEKVoDn0CSep89TtPyGpX8oWUd5k37rLFZZ+1U6HPf1dYl8x MsJkstgG6ixvV2TosSIpMBTImk2iIPo7HHQZ9m6sZIWmvI/oIU8GmIvZxZICh2hWzVoH Igvg== X-Gm-Message-State: AElRT7EdYXsod1m7CTl5Q1/N2Q2Qnc4dLM0fMYvH35pR+7UPe7d1Nz9Q FZAofZKN0o4eLUtTninE9XOG6nzMl70= X-Google-Smtp-Source: AIpwx4/EovZkqXRhCoUFiO0aZ2sckoHJoVLx2YlX/z1R2YddzEc5vLvMYn2vW1MaXseRK+uEDFDelA== X-Received: by 10.80.189.138 with SMTP id y10mr7609813edh.249.1522788262532; Tue, 03 Apr 2018 13:44:22 -0700 (PDT) Received: from mutt-hbsd ([185.104.120.60]) by smtp.gmail.com with ESMTPSA id i48sm2271940ede.39.2018.04.03.13.44.20 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 03 Apr 2018 13:44:21 -0700 (PDT) Date: Tue, 3 Apr 2018 16:44:10 -0400 From: Shawn Webb To: Brooks Davis Cc: freebsd-toolchain@freebsd.org, Ali Mashtizadeh Subject: Re: splitting libc -> libc + libsys and static linking Message-ID: <20180403204410.zfxziemnzeiejqlp@mutt-hbsd> References: <20180403203210.GA23045@spindle.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="dbgvktdl2m5aziov" Content-Disposition: inline In-Reply-To: <20180403203210.GA23045@spindle.one-eyed-alien.net> X-Operating-System: FreeBSD mutt-hbsd 12.0-CURRENT FreeBSD 12.0-CURRENT X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20171215 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 20:44:24 -0000 --dbgvktdl2m5aziov Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 03, 2018 at 08:32:10PM +0000, Brooks Davis wrote: > We (mostly Ali) are working on a patch to to split the actual syscalls > (__sys_) out of libc and into a libsys. For dynamic linking, > this is fairly straightforward (link libc against libsys, maybe as a > filter). For static linking, I'm looking for feedback on the right > approach. Do we link libsys.a into libc.a? Do we try to teach all the > compilers to add -lsys? I'm pretty sure we don't modify all the ports > that statically link programs. Is there some easy approach I'm missing? Hey Brooks, I'm curious about the reasoning behind this change. Could you explain in more detail why you'd like to create a libsys? Thanks, --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD Tor-ified Signal: +1 443-546-8752 Tor+XMPP+OTR: lattera@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --dbgvktdl2m5aziov Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAlrD55YACgkQaoRlj1JF bu6IRxAArWO8pudmzUWfvWWEYFfhWfJSc4vfrBzQ1kFFnCwQeN+iONG3F2ZTpWde bvuxtkjWX5mDPCkw/sUBDqRbgg0NPi5hl6M3GPcQuA3tkNGDqcAVD/N94P7y9cMR Cg9qCEHqT+uNccigNdeVK0FKUxG38rBq9ExwP5pWiMbsu2+7YMNDel/aTi5s8fXO p6ZKPHLBpEQ0qWXlFO0AxwjxSEAWS8tpxBoGKQwUVyRvCK+2TUgoenxzwz0CU4eI kjjtMauDe8ZOqOPICb2H9T+oDg7n6tXTZfUxLfYnfAfp+nOQGKBCSJAg9CYwus6/ qNfkDNQJ9T1Bs8vnO1Oy1tX6Uweh1S1RmQ6BlbfGHgtLUg2zab5M385vd4aFH3b9 kyrxWCLrQfTz53GDwJVxhk+tU638JMu8556bi2HmWB/L5DdjJCk/APm3l5gxp17S z+weGjW2rS47j2vfksS+VZIwJPOP9tVZZHzh8jgcGoVwjfI4oPJLjbN/pT2il900 M4bTMUBTLSriVVSdHclnQhLvfOlif8Io9FE3flrz/TZPlIVwpoINX9D1usRkyKzs 5z5IyGGFhd0R5Ynrfg0CVwzZ9gMTRxhpS8n5aTpTH4WpsUQ6OasjUoDS6Rt3eATF AbG2lWHVDpMa/KACYL9dLFbbDCAu9aoFzl3Axdp+8lzb7xp9e7U= =MzEX -----END PGP SIGNATURE----- --dbgvktdl2m5aziov-- From owner-freebsd-toolchain@freebsd.org Tue Apr 3 20:59:31 2018 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D93FFF7FFCE for ; Tue, 3 Apr 2018 20:59:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3957B741A5; Tue, 3 Apr 2018 20:59:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id w33KxK51071281 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 3 Apr 2018 23:59:23 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua w33KxK51071281 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id w33KxK6u071280; Tue, 3 Apr 2018 23:59:20 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 3 Apr 2018 23:59:20 +0300 From: Konstantin Belousov To: Dimitry Andric Cc: Brooks Davis , freebsd-toolchain@freebsd.org, Ali Mashtizadeh Subject: Re: splitting libc -> libc + libsys and static linking Message-ID: <20180403205920.GP1774@kib.kiev.ua> References: <20180403203210.GA23045@spindle.one-eyed-alien.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 20:59:32 -0000 On Tue, Apr 03, 2018 at 10:39:44PM +0200, Dimitry Andric wrote: > On 3 Apr 2018, at 22:32, Brooks Davis wrote: > > > > We (mostly Ali) are working on a patch to to split the actual syscalls > > (__sys_) out of libc and into a libsys. For dynamic linking, > > this is fairly straightforward (link libc against libsys, maybe as a > > filter). For static linking, I'm looking for feedback on the right > > approach. Do we link libsys.a into libc.a? Do we try to teach all the > > compilers to add -lsys? I'm pretty sure we don't modify all the ports > > that statically link programs. Is there some easy approach I'm missing? > > The approach chosen for e.g. libc++ (and before that, libstdc++), was to > put all needed objects from the dependent libs in the same .a file. This would make libsys.a half as useless. One of the indended use of libsys.a in the base system is to get rid of libc in rtld dependencies. Try to experiment with the linker script for libc.a. > > See: > https://svnweb.freebsd.org/base/head/lib/libc%2B%2B/Makefile?revision=321369&view=markup#l61 > > and: > https://svnweb.freebsd.org/base/head/gnu/lib/libstdc%2B%2B/Makefile?revision=315175&view=markup#l57 > > For dynamic linking, you could use your approach of putting libsys in > the NEEDED section, or add it to the libc.so linker script, like what is > done for libc++.so. For dynamic library, this is wrong. libsys must not appear in the dependency list of the final binaries, otherwise you break ABI and old binaries which were not linked against libsys. This library only contains private-namespace symbols, and should be not exposed to applications. As was already mentioned, a filtering for the libsys.so symbols in libc is good enough approach. From owner-freebsd-toolchain@freebsd.org Tue Apr 3 21:16:12 2018 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0BBACF81379 for ; Tue, 3 Apr 2018 21:16:12 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A78197510F for ; Tue, 3 Apr 2018 21:16:11 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id BF5CD5A9F16; Tue, 3 Apr 2018 21:16:10 +0000 (UTC) Date: Tue, 3 Apr 2018 21:16:10 +0000 From: Brooks Davis To: Shawn Webb Cc: Brooks Davis , freebsd-toolchain@freebsd.org, Ali Mashtizadeh Subject: Re: splitting libc -> libc + libsys and static linking Message-ID: <20180403211610.GB23045@spindle.one-eyed-alien.net> References: <20180403203210.GA23045@spindle.one-eyed-alien.net> <20180403204410.zfxziemnzeiejqlp@mutt-hbsd> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xXmbgvnjoT4axfJE" Content-Disposition: inline In-Reply-To: <20180403204410.zfxziemnzeiejqlp@mutt-hbsd> User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2018 21:16:12 -0000 --xXmbgvnjoT4axfJE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 03, 2018 at 04:44:10PM -0400, Shawn Webb wrote: > On Tue, Apr 03, 2018 at 08:32:10PM +0000, Brooks Davis wrote: > > We (mostly Ali) are working on a patch to to split the actual syscalls > > (__sys_) out of libc and into a libsys. For dynamic linking, > > this is fairly straightforward (link libc against libsys, maybe as a > > filter). For static linking, I'm looking for feedback on the right > > approach. Do we link libsys.a into libc.a? Do we try to teach all the > > compilers to add -lsys? I'm pretty sure we don't modify all the ports > > that statically link programs. Is there some easy approach I'm missing? >=20 > I'm curious about the reasoning behind this change. Could you explain > in more detail why you'd like to create a libsys? In CheriBSD I use something like this to let me use the same libc inside and outside sandboxes while varying the syscall implementation. Ali is (IIRC) using it in a record and playback framework. It could potentially let us link a libsys_pic.a into libthr.so and rtld to eliminate the need for syscall(2). It could also ease experimentation with alternative syscall invocation methods (e.g. I've got a branch of CheriBSD where the ability to make a given syscall is controlled by possession of an unforgable token.) Having a clear interface in a separate library makes it easier to know what to replace and gives a clear place to do it. -- Brooks --xXmbgvnjoT4axfJE Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJaw+8aAAoJEKzQXbSebgfAGXcH/jhPtivSOGvx69L4cUadt0mb 61Yy0bJyp3Vyx7SJb2zBA5ZJ/XXR9l+mC9H2QrAu5fZuYW6e3pLGQzHf+J1e1bH5 hFH7AEPnp36/2rNvX9jzYFZONCpiRa180TfvRhVANMEpEclUlWGfIspmPiOVhWPy Eymud4srw/+ryoWzl/bsdAcAIsTQqp7SooDulDMkNngn3OsGlOVMFV57s/lTiHnR qN1HVuwG8AVXE0/zmIgpLd9XGCaFITaTFzGBBxeeCEttRvdWj0ZubcNyS1j30byx 2AK5i3RlYtBcT3wphZVsO1aK48A2jUFE1QTREfaRDTPZ3ibHu4e8gh6uCY2KlQo= =d1qH -----END PGP SIGNATURE----- --xXmbgvnjoT4axfJE-- From owner-freebsd-toolchain@freebsd.org Thu Apr 5 03:15:37 2018 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DEA17F81F64; Thu, 5 Apr 2018 03:15:36 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::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 6BF6983721; Thu, 5 Apr 2018 03:15:36 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-it0-x22e.google.com with SMTP id x144-v6so563678itc.0; Wed, 04 Apr 2018 20:15:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=KGWewgYzglIgN1TSkmgInVf8tLz9ZvJ5v40KtWpu9AE=; b=ZoWPFxjYanC9ZpOMvTd0Yt6rmhn7iI8SYPbHGSfBkhsWQxpBAylc0ZL1NROnMOiqhv MSy9Cag5yfwSB5ey6ag2sY5mXD9lb4/jL4h1FsJqMjBs+soEQFG/SwJYuhCPj8yEQs5g +NP9Tp9Yq8Wf3sjtLweFxUlXqwrGdxNWwYZtnrcL2EiYZlSxshg5BoHf/BIsGRw0f/if uwmGhQltQVfpG4xcdVxZmG0NS+7bTTKMFGbm33i1HDfg5WkTtn+nyGj8QvqG4uj+Qz/a zh0AS5eheZ3UTRuDvlICFyQeSoIfY1S6BW911TyJHPL53l2SQylo+Y/eOBprdq25GogJ DEUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=KGWewgYzglIgN1TSkmgInVf8tLz9ZvJ5v40KtWpu9AE=; b=XWvW6tHdoI3sH0gndgpt/K0LPrB981jp/KifCneNTiOSKUGAVIPC4vNKzv/f2xf/Ph xr9/1TCUZu4K5lizVGkuN6MVWE2LDy/3PKQ9vfDRj9/P4IZP0yjCki591c4inb+WFGAY pGr0lCsXQdBvkBBDUnu/1iYyMDs98C+paqV3wZCGe6cHZ/f1Pt85pqhLWozpYhyLctRd 2Kseqw2BJa6G3ovOSqx6LGGcMXEVX9tAe7znaIAMkHFAVeKzSiJ2qy39THITnikJA5wC 9t13i0OcKI72tfUGO1V8UjFQOQmFAnBDGIYxugd/jGYSIiUT5QPgbjSt3QHrEjCBPWXE MefQ== X-Gm-Message-State: AElRT7ESVhYzJ04G/Cn6nK7v+12+zIswG1lOeaoIaX/26pOnmcS5nVCA B1qxdE2evzobZPOLlu9gss8x4mqGvCnlG4/3ldygfEHQ X-Google-Smtp-Source: AIpwx4/qgCxlbTrbWUHg5QC0BxHU3Hh5h0ZRhrIw+1C6aTsMj3tW/86Nymt0RVz2yrcIIPVKC0H7DXBzuxJCX9dsDdI= X-Received: by 2002:a24:dfc3:: with SMTP id r186-v6mr11733601itg.114.1522898135674; Wed, 04 Apr 2018 20:15:35 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.130.197 with HTTP; Wed, 4 Apr 2018 20:15:15 -0700 (PDT) In-Reply-To: References: From: Ed Maste Date: Wed, 4 Apr 2018 23:15:15 -0400 X-Google-Sender-Auth: 9wV38CW97DtW2al8sLKPLs2QM_0 Message-ID: Subject: Re: Heads-up: linker (lld) changes for amd64 coming soon To: "freebsd-toolchain@FreeBSD.org" , FreeBSD Ports Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2018 03:15:37 -0000 On 29 March 2018 at 13:14, Ed Maste wrote: > > There are now 14 PRs open for failures when lld is /usr/bin/ld. Now down to 5: PR 221800 - www/mod_jk Appears to be an issue with libtool passing through linker flags. 0 dependent ports skipped. PR 224673 - misc/seabios Port maintainer has patch ready to be committed. 2 dependent ports skipped PR 226872 - lang/ghc Haskell compiler - the compiler builds fine by using ld.bfd via $LD, but then the built compiler invokes ld. Report in the PR claims the current version (8.4.1) includes some lld support so might "just work" after the port's updated? 558 dependent ports skipped. PR 226975 - x11/eaglemode A common case due to disagreement about preemption of symbols with protected visibility in a shared library. 0 dependent ports skipped. PR 226980 - several ports using openal Ports using openal failed due to the protected visibility symbol preemption issue. LLD_UNSAFE has been added to many of them, with 14 more to go. As a group, 1 dependent port skipped. From owner-freebsd-toolchain@freebsd.org Sat Apr 7 22:24:00 2018 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BB354F8ADEA for ; Sat, 7 Apr 2018 22:24:00 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic316-21.consmr.mail.ne1.yahoo.com (sonic316-21.consmr.mail.ne1.yahoo.com [66.163.187.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 166E581497 for ; Sat, 7 Apr 2018 22:23:59 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: rSRY_AEVM1mLnVPAp5NGHOivbBAQwY3u4jsEbLeHCV43OecNj9XgnjMcaDjQ9bS XwMszTfCnCbIZqsWkU0p3KJ5pTGBbkq2TkBtDCp4T75O5y6SqfL6afZJE5p9JLbvNIKFb26MPXFY 7S6f5WLWrVaDL9tN8oCdhMXG31EXnK4LITvoemsVZ1G7HuyvW01ucExdZEdb_ZUMsEAVYa.TBiVs QouKuRhQ8DtdCrYD67rkGweS0sYy0d1Hjm32tdpCk5JChLd3h2LW6CfCPrmOIT3Y5UEIMtXdbnaF WT4gnWeve6fCNUZAGnv0w23_ALo62E0H9sWWfCb4fOSxICi.XyPnm5fitxq4d2037aK0uhTnNCtI ine_2H1.ZwKZ6ddpd_qIKFkms9r56PSc2oFbESngFqKahGxL20QjoTdBxtBTUuKSySCWlKWOTCEB 60jrRPF6JJ0R.kU3jluu_7yw7yGkgz8d72jGsItx7vs0UPqKlNFkFnNfv_RM8g4WCfqbUdIw9xKW RM2W_gLmqTKzb.hXyDDZKkmgQjQxEUypCZ36P_Bsg50d8rOFVtq_melM- Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.ne1.yahoo.com with HTTP; Sat, 7 Apr 2018 22:23:53 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp421.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 74dfe8ce1c4eb01dafbb95d8ef92c27d; Sat, 07 Apr 2018 22:23:51 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Subject: Attempting a xtoolchain-gcc head amd64->aarch64 cross buildworld failed for liblto_plugin.so loading error Message-Id: Date: Sat, 7 Apr 2018 15:23:50 -0700 To: freebsd-toolchain@freebsd.org, FreeBSD Ports , freebsd-arm@freebsd.org X-Mailer: Apple Mail (2.3445.6.18) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2018 22:24:01 -0000 My attempted, xtoolchain-gcc based, amd64->aarch64 = cross-buildworld-buildkernel failed with: --- libc.so.7.full --- /usr/local/bin/aarch64-unknown-freebsd12.0-ld: = /usr/local/libexec/gcc/aarch64-unknown-freebsd12.0/6.3.0/liblto_plugin.so:= error loading plugin: Service unavailable collect2: error: ld returned 1 exit status *** [libc.so.7.full] Error code 1 (I've not attempted such a build in a long time, so I do not know how new this is. Historically I've done lots of such builds. cortex-a53 was specifically targeted here.) For reference: # uname -apKU FreeBSD FBSDFSSD 12.0-CURRENT FreeBSD 12.0-CURRENT r332181M amd64 = amd64 1200061 1200061 # pkg info "*binutils" aarch64-binutils-2.30_2,1 amd64-binutils-2.30_2,1 binutils-2.30_2,1 powerpc64-binutils-2.30_2,1 # svnlite info /usr/ports/ | grep "Re[plv]" Relative URL: ^/head Repository Root: svn://svn.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 466704 Last Changed Rev: 466704 # file /usr/local/libexec/gcc/*/*/liblto* = /usr/local/libexec/gcc/aarch64-unknown-freebsd12.0/6.3.0/liblto_plugin.so:= symbolic link to liblto_plugin.so.0.0.0 = /usr/local/libexec/gcc/aarch64-unknown-freebsd12.0/6.3.0/liblto_plugin.so.= 0: symbolic link to liblto_plugin.so.0.0.0 = /usr/local/libexec/gcc/aarch64-unknown-freebsd12.0/6.3.0/liblto_plugin.so.= 0.0.0: ELF 64-bit LSB shared object, x86-64, version 1 (FreeBSD), = dynamically linked, with debug_info, not stripped = /usr/local/libexec/gcc/powerpc64-unknown-freebsd12.0/6.3.0/liblto_plugin.s= o: symbolic link to liblto_plugin.so.0.0.0 = /usr/local/libexec/gcc/powerpc64-unknown-freebsd12.0/6.3.0/liblto_plugin.s= o.0: symbolic link to liblto_plugin.so.0.0.0 = /usr/local/libexec/gcc/powerpc64-unknown-freebsd12.0/6.3.0/liblto_plugin.s= o.0.0.0: ELF 64-bit LSB shared object, x86-64, version 1 (FreeBSD), = dynamically linked, with debug_info, not stripped = /usr/local/libexec/gcc/x86_64-unknown-freebsd12.0/6.3.0/liblto_plugin.so: = symbolic link to liblto_plugin.so.0.0.0 = /usr/local/libexec/gcc/x86_64-unknown-freebsd12.0/6.3.0/liblto_plugin.so.0= : symbolic link to liblto_plugin.so.0.0.0 = /usr/local/libexec/gcc/x86_64-unknown-freebsd12.0/6.3.0/liblto_plugin.so.0= .0.0: ELF 64-bit LSB shared object, x86-64, version 1 (FreeBSD), = dynamically linked, with debug_info, not stripped make[4]: stopped in /usr/src/lib/libc .ERROR_TARGET=3D'libc.so.7.full' = .ERROR_META_FILE=3D'/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/sr= c/arm64.aarch64/lib/libc/libc.so.7.full.meta' .MAKE.LEVEL=3D'4' MAKEFILE=3D'' .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes = verbose' _ERROR_CMD=3D'@echo building shared library libc.so.7; @rm -f libc.so.7 = libc.so; /usr/local/bin/aarch64-unknown-freebsd12.0-gcc -mcpu=3Dcortex-a53= -isystem = /usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/arm64.aarch64/tmp/= usr/include = -L/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/arm64.aarch64/tm= p/usr/lib = -B/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/arm64.aarch64/tm= p/usr/lib = --sysroot=3D/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/arm64.= aarch64/tmp -B/usr/local/aarch64-unknown-freebsd12.0/bin/ = -nodefaultlibs -Wl,--version-script=3DVersion.map -shared -Wl,-x = -Wl,--fatal-warnings -Wl,--warn-shared-textrel -o libc.so.7.full = -Wl,-soname,libc.so.7 = `NM=3D'/usr/local/aarch64-unknown-freebsd12.0/bin/nm' NMFLAGS=3D'' = lorder machdep_ldisQ.pico . . . wcspbrk.pico wcsrchr.pico wcsspn.pico wcsstr.pico wcstok.pico = wcswidth.pico wcsxfrm.pico wmemchr.pico wmemcmp.pico wmemcpy.pico = wmemmove.pico wmemset.pico | tsort -q` -lcompiler_rt = -lssp_nonshared;' .CURDIR=3D'/usr/src/lib/libc' .MAKE=3D'make' = .OBJDIR=3D'/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/arm64.a= arch64/lib/libc' .TARGETS=3D'all' = DESTDIR=3D'/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/arm64.a= arch64/tmp' LD_LIBRARY_PATH=3D'' MACHINE=3D'arm64' MACHINE_ARCH=3D'aarch64' MAKEOBJDIRPREFIX=3D'' MAKESYSPATH=3D'/usr/src/share/mk' MAKE_VERSION=3D'20180222' = PATH=3D'/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/arm64.aarc= h64/tmp/legacy/usr/sbin:/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/us= r/src/arm64.aarch64/tmp/legacy/usr/bin:/usr/obj/cortexA53_xtoolchain-gcc/a= rm64.aarch64/usr/src/arm64.aarch64/tmp/legacy/bin:/usr/obj/cortexA53_xtool= chain-gcc/arm64.aarch64/usr/src/arm64.aarch64/tmp/usr/sbin:/usr/obj/cortex= A53_xtoolchain-gcc/arm64.aarch64/usr/src/arm64.aarch64/tmp/usr/bin:/sbin:/= bin:/usr/sbin:/usr/bin' SRCTOP=3D'/usr/src' = OBJTOP=3D'/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/arm64.aa= rch64' .MAKE.MAKEFILES=3D'/usr/src/share/mk/sys.mk = /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk = /root/src.configs/src.conf.cortexA53-xtoolchain-gcc.amd64-host = /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/src.sys.obj.mk = /usr/src/share/mk/auto.obj.mk /usr/src/share/mk/bsd.suffixes.mk = /root/src.configs/make.conf /usr/src/share/mk/local.sys.mk = /usr/src/share/mk/src.sys.mk /dev/null /usr/src/lib/libc/Makefile = /usr/src/share/mk/src.opts.mk /usr/src/share/mk/bsd.own.mk = /usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.cpu.mk = /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.linker.mk = /usr/src/lib/libc/aarch64/Makefile.inc /usr/src/lib/libc/db/Makefile.inc = /usr/src/lib/libc/db/btree/Makefile.inc = /usr/src/lib/libc/db/db/Makefile.inc = /usr/src/lib/libc/db/hash/Makefile.inc = /usr/src/lib/libc/db/man/Makefile.inc = /usr/src/lib/libc/db/mpool/Makefile.inc = /usr/src/lib/libc/db/recno/Makefile.inc = /usr/src/lib/libc/compat-43/Makefile.inc = /usr/src/lib/libc/gdtoa/Makefile.inc /usr/src/lib/libc/gen/Makefile.inc = /usr/src/lib/libc/aarch64/gen/Makefile.inc = /usr/src/lib/libc/gmon/Makefile.inc /usr/src/lib/libc/iconv/Makefile.inc = /usr/src/lib/libc_nonshared/Makefile.iconv = /usr/src/lib/libc/inet/Makefile.inc /usr/src/lib/libc/isc/Makefile.inc = /usr/src/lib/libc/locale/Makefile.inc /usr/src/lib/libc/md/Makefile.inc = /usr/src/lib/libc/nameser/Makefile.inc = /usr/src/lib/libc/net/Makefile.inc /usr/src/lib/libc/nls/Makefile.inc = /usr/src/lib/libc/posix1e/Makefile.inc = /usr/src/lib/libc/regex/Makefile.inc = /usr/src/lib/libc/resolv/Makefile.inc = /usr/src/lib/libc/stdio/Makefile.inc = /usr/src/lib/libc/stdlib/Makefile.inc = /usr/src/lib/libc/stdlib/jemalloc/Makefile.inc = /usr/src/lib/libc/stdtime/Makefile.inc = /usr/src/lib/libc/string/Makefile.inc = /usr/src/lib/libc/aarch64/string/Makefile.inc = /usr/src/lib/libc/sys/Makefile.inc /usr/src/sys/sys/syscall.mk = /usr/src/lib/libc/aarch64/sys/Makefile.inc = /usr/src/lib/libc/secure/Makefile.inc /usr/src/lib/libc/rpc/Makefile.inc = /usr/src/lib/libc/uuid/Makefile.inc /usr/src/lib/libc/xdr/Makefile.inc = /usr/src/lib/libc/yp/Makefile.inc = /usr/src/lib/libc/capability/Makefile.inc /usr/src/share/mk/bsd.lib.mk = /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/local.init.mk = /usr/src/share/mk/src.init.mk /usr/src/lib/libc/../Makefile.inc = /usr/src/share/mk/bsd.libnames.mk /usr/src/share/mk/src.libnames.mk = /usr/src/share/mk/bsd.symver.mk /usr/src/share/mk/bsd.nls.mk = /usr/src/share/mk/bsd.files.mk /usr/src/share/mk/bsd.incs.mk = /usr/src/share/mk/bsd.confs.mk /usr/src/share/mk/bsd.links.mk = /usr/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.mk = /usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk = /usr/src/share/mk/bsd.sys.mk' .PATH=3D'. /usr/src/lib/libc /usr/src/lib/libc/db/btree = /usr/src/lib/libc/db/db /usr/src/lib/libc/db/hash = /usr/src/lib/libc/db/man /usr/src/lib/libc/db/mpool = /usr/src/lib/libc/db/recno /usr/src/lib/libc/compat-43 = /usr/src/lib/libc/gdtoa /usr/src/lib/libc/aarch64/gen = /usr/src/lib/libc/gen /usr/src/contrib/libc-pwcache = /usr/src/contrib/libc-vis /usr/src/lib/libc/gmon /usr/src/lib/libc/iconv = /usr/src/lib/libc/inet /usr/src/lib/libc/isc /usr/src/lib/libc/locale = /usr/src/lib/libmd /usr/src/lib/libc/nameser /usr/src/lib/libc/net = /usr/src/lib/libc/nls /usr/src/lib/libc/posix1e /usr/src/lib/libc/regex = /usr/src/lib/libc/resolv /usr/src/lib/libc/stdio = /usr/src/lib/libc/stdlib /usr/src/lib/libc/stdlib/jemalloc = /usr/src/lib/libc/stdtime /usr/src/contrib/tzcode/stdtime = /usr/src/lib/libc/aarch64/string /usr/src/lib/libc/string = /usr/src/sys/libkern /usr/src/contrib/cortex-strings/src/aarch64 = /usr/src/lib/libc/aarch64/sys /usr/src/lib/libc/sys = /usr/src/lib/libc/secure /usr/src/lib/libc/rpc /usr/src/lib/libc/. = /usr/src/lib/libc/uuid /usr/src/lib/libc/xdr /usr/src/lib/libc/yp = /usr/src/sys/kern /usr/src/lib/libc/capability' 1 error =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-toolchain@freebsd.org Sat Apr 7 22:30:18 2018 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1E440F8B31A for ; Sat, 7 Apr 2018 22:30:18 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic305-4.consmr.mail.bf2.yahoo.com (sonic305-4.consmr.mail.bf2.yahoo.com [74.6.133.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BBE7984BEA for ; Sat, 7 Apr 2018 22:30:17 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: vCzQaGgVM1nun91Gsa_ffto6EKtEwCvtHFL_36VfXTG6Ka8ePs.RoOiPiwluY_5 Emw0o_ARvbbR_xTJVF6rqgIfWS.jF9kyRdjMdFecrJAUJMLqEQRIPfgLHuTp6KKQrCkEr66LUhkK EFe07YKVKqCzO1Uk0EdEgd9nyo3l2MXd7p_rwA2O8PwlUsijd2WQ05FxkQL1OIlmnGhMo5TXi558 Dx4qWqOI5i6roRvwhz9Vvi_G9_LW98luf_DyGOBKRnB4LeQxPi3.f1qFEwhVPbEqPtOfOoFB446O 7g4xBF47TsPXQaSecYhLS2q7NoMnInuNFLfRIB4BMMgRYYm9.Z0xWoaCBXWldHFYK0voescgh3YV EHc5kpgkejGV180naOBBHkxMK6wMTPAbECXjl0pdw64ATxzcpVO0cWM9_CK7uJa0d3xhRSwjpvXw SaPJILFrH1ROuoQOvHVplqqyi6et_rYEoAAW5w7JmDu7N6DUckjTpq_fUQAQjwL4RbUhB5sIYZhR 6DytrAJMxiGUEbnzYfcxiaGJVXbCvRahOa.dS Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.bf2.yahoo.com with HTTP; Sat, 7 Apr 2018 22:30:11 +0000 Received: from c-76-115-7-162.hsd1.or.comcast.net (EHLO [192.168.1.25]) ([76.115.7.162]) by smtp431.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID e25ccc9852b5bd675a104b3c6c55ba4d; Sat, 07 Apr 2018 22:30:09 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Subject: amd64-binutils file name structure for utils vs. for powerpc64-binutils and aarch64-binutils Message-Id: Date: Sat, 7 Apr 2018 15:30:08 -0700 To: freebsd-toolchain@freebsd.org, FreeBSD Ports X-Mailer: Apple Mail (2.3445.6.18) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2018 22:30:18 -0000 For: # pkg info "*binutils" aarch64-binutils-2.30_2,1 amd64-binutils-2.30_2,1 binutils-2.30_2,1 powerpc64-binutils-2.30_2,1 # svnlite info /usr/ports/ | grep "Re[plv]" Relative URL: ^/head Repository Root: svn://svn.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 466704 Last Changed Rev: 466704 in a amd64 context . . . amd64-binutils uses file naming that does not match the patterns that aarch64-binutils and powerpc64-binutils use. Using an example type of binutil for illustration (in a 12.0 head context): # find /usr/local/bin /usr/local/*freebsd* -name "*addr2line*" -print /usr/local/bin/powerpc64-unknown-freebsd12.0-addr2line /usr/local/bin/x86_64-freebsd-addr2line /usr/local/bin/addr2line /usr/local/bin/aarch64-unknown-freebsd12.0-addr2line The differences involve the lack of: -unknown 12.0 (Of course, plain binutils does not have such conventions.) Is this expected/intended? For reference: # uname -apKU FreeBSD FBSDFSSD 12.0-CURRENT FreeBSD 12.0-CURRENT r332181M amd64 = amd64 1200061 1200061 =3D=3D=3D Mark Millard marklmi26-fbsd at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-toolchain@freebsd.org Sat Apr 7 22:35:33 2018 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A1EB5F8B84D; Sat, 7 Apr 2018 22:35:33 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (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 322CF87C8F; Sat, 7 Apr 2018 22:35:33 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: by mail-qt0-x236.google.com with SMTP id d3so5034735qth.8; Sat, 07 Apr 2018 15:35:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version; bh=lTac+OCRvvHvapXdleMgp0U8asMrlF90RCOxgNb2q4Y=; b=kMoNQ8xtJ/PMWWyawp4BhAWxlZG94TTIRJZQ026BWUk4nup3+8mtIxAHE0eyBz4J8u Cd/050zB8tUx5tBR0DHuzN42N7mgVH9UFJTU8UwIW/tglszVF6qfgzrg3+P13og2/d/C bVu8Wy8XdcOmyJdqr+B8h+tiMub+spiQtO1qaBvDAbEP5rLM2Yfl4kODqGc9Lmmzohs/ pRq6YEPC/OscuA8iVNYh4yx+dN2tHuFHUOLjV0imrT+Sbke+fzyCINI3I+S3euGif+Wo 4WWHcRMbCrmTHCp62PAp9m0BlEieoxCA2AGsrQY+KROxBcGipWs8J9hGG4jCownDDsWG EjFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version; bh=lTac+OCRvvHvapXdleMgp0U8asMrlF90RCOxgNb2q4Y=; b=Yok+LdG4QUl6ZSNPNM0PmxqEDgLuKIWl8LbhgcoXKQSx3b6s9iZ7nueIgvBVvkr1wP kMUoIXhe07pBh63uSx7CpQe/GQTKHc2EsU0QFukQJH/876+ymJTExTt25TNEKp6TNaWg X4bgrh40i3Q5qfn1vyFxheA1DFvbPo+iv7zoVcXGCJGNAAtKLrJ/4ai2cBjI4jB3ZpP+ KmLRVk9+3ETwELNchLdRFLRj2boj20TnvtCekpMGkseUCFbZwQWd/e9eqlpifHFLJEIp HbID2mhC3gfR3hxbj6MX1tDmoNGzL5Sr3uH6FbgCX//BvdjuuIJlfe9HGjsrJirqPeOP QlhQ== X-Gm-Message-State: ALQs6tBDBXAZMr3QBEzeWHQdPedbzCECu4clWh195BgPLzGAVlIyUbVZ bW0coXQRvTOmVlPeLPLl2r7von6L X-Google-Smtp-Source: AIpwx4/IVMsvrL8qlYifKFvfmKuXbx5Vim5w7l/84mtjvtv83ibJOCyMLWpnhmhIPg4Vkz8tm5J6Hw== X-Received: by 10.200.22.50 with SMTP id p47mr44544433qtj.135.1523140532454; Sat, 07 Apr 2018 15:35:32 -0700 (PDT) Received: from kan ([2601:18f:802:4680:226:18ff:fe00:232e]) by smtp.gmail.com with ESMTPSA id k50sm11346845qtb.96.2018.04.07.15.35.31 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 07 Apr 2018 15:35:31 -0700 (PDT) Date: Sat, 7 Apr 2018 18:35:25 -0400 From: Alexander Kabaev To: Mark Millard via freebsd-arm Cc: Mark Millard , freebsd-toolchain@freebsd.org, FreeBSD Ports Subject: Re: Attempting a xtoolchain-gcc head amd64->aarch64 cross buildworld failed for liblto_plugin.so loading error Message-ID: <20180407183525.2e72ee42@kan> In-Reply-To: References: X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/0q2gf+JoULIeb6Raj+5ZdbV"; protocol="application/pgp-signature" X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2018 22:35:33 -0000 --Sig_/0q2gf+JoULIeb6Raj+5ZdbV Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sat, 7 Apr 2018 15:23:50 -0700 Mark Millard via freebsd-arm wrote: > My attempted, xtoolchain-gcc based, amd64->aarch64 > cross-buildworld-buildkernel failed with: >=20 > --- libc.so.7.full --- > /usr/local/bin/aarch64-unknown-freebsd12.0-ld: /usr/local/libexec/gcc/aar= ch64-unknown-freebsd12.0/6.3.0/liblto_plugin.so: > error loading plugin: Service unavailable collect2: error: ld > returned 1 exit status *** [libc.so.7.full] Error code 1 >=20 > (I've not attempted such a build in a long time, so I do not > know how new this is. Historically I've done lots of such > builds. cortex-a53 was specifically targeted here.) >=20 > For reference: >=20 > # uname -apKU > FreeBSD FBSDFSSD 12.0-CURRENT FreeBSD 12.0-CURRENT r332181M amd64 > amd64 1200061 1200061 >=20 > # pkg info "*binutils" > aarch64-binutils-2.30_2,1 > amd64-binutils-2.30_2,1 > binutils-2.30_2,1 > powerpc64-binutils-2.30_2,1 >=20 > # svnlite info /usr/ports/ | grep "Re[plv]" > Relative URL: ^/head > Repository Root: svn://svn.freebsd.org/ports > Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 > Revision: 466704 > Last Changed Rev: 466704 >=20 > # file /usr/local/libexec/gcc/*/*/liblto* > /usr/local/libexec/gcc/aarch64-unknown-freebsd12.0/6.3.0/liblto_plugin.so: > symbolic link to > liblto_plugin.so.0.0.0 /usr/local/libexec/gcc/aarch64-unknown-freebsd12.0= /6.3.0/liblto_plugin.so.0: > symbolic link to > liblto_plugin.so.0.0.0 /usr/local/libexec/gcc/aarch64-unknown-freebsd12.0= /6.3.0/liblto_plugin.so.0.0.0: > ELF 64-bit LSB shared object, x86-64, version 1 (FreeBSD), > dynamically linked, with debug_info, not > stripped /usr/local/libexec/gcc/powerpc64-unknown-freebsd12.0/6.3.0/liblt= o_plugin.so: > symbolic link to > liblto_plugin.so.0.0.0 /usr/local/libexec/gcc/powerpc64-unknown-freebsd12= .0/6.3.0/liblto_plugin.so.0: > symbolic link to > liblto_plugin.so.0.0.0 /usr/local/libexec/gcc/powerpc64-unknown-freebsd12= .0/6.3.0/liblto_plugin.so.0.0.0: > ELF 64-bit LSB shared object, x86-64, version 1 (FreeBSD), > dynamically linked, with debug_info, not > stripped /usr/local/libexec/gcc/x86_64-unknown-freebsd12.0/6.3.0/liblto_p= lugin.so: > symbolic link to > liblto_plugin.so.0.0.0 /usr/local/libexec/gcc/x86_64-unknown-freebsd12.0/= 6.3.0/liblto_plugin.so.0: > symbolic link to > liblto_plugin.so.0.0.0 /usr/local/libexec/gcc/x86_64-unknown-freebsd12.0/= 6.3.0/liblto_plugin.so.0.0.0: > ELF 64-bit LSB shared object, x86-64, version 1 (FreeBSD), > dynamically linked, with debug_info, not stripped >=20 >=20 >=20 > make[4]: stopped in /usr/src/lib/libc > .ERROR_TARGET=3D'libc.so.7.full' > .ERROR_META_FILE=3D'/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/s= rc/arm64.aarch64/lib/libc/libc.so.7.full.meta' > .MAKE.LEVEL=3D'4' > MAKEFILE=3D'' > .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes > verbose' _ERROR_CMD=3D'@echo building shared library libc.so.7; @rm -f > libc.so.7 libc.so; /usr/local/bin/aarch64-unknown-freebsd12.0-gcc > -mcpu=3Dcortex-a53 > -isystem /usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/arm64.aa= rch64/tmp/usr/include > -L/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/arm64.aarch64/t= mp/usr/lib > -B/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/arm64.aarch64/t= mp/usr/lib > --sysroot=3D/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/arm64= .aarch64/tmp > -B/usr/local/aarch64-unknown-freebsd12.0/bin/ -nodefaultlibs > -Wl,--version-script=3DVersion.map -shared -Wl,-x -Wl,--fatal-warnings > -Wl,--warn-shared-textrel -o libc.so.7.full -Wl,-soname,libc.so.7 > `NM=3D'/usr/local/aarch64-unknown-freebsd12.0/bin/nm' NMFLAGS=3D'' lorder > machdep_ldisQ.pico . . . wcspbrk.pico wcsrchr.pico wcsspn.pico > wcsstr.pico wcstok.pico wcswidth.pico wcsxfrm.pico wmemchr.pico > wmemcmp.pico wmemcpy.pico wmemmove.pico wmemset.pico | tsort -q` > -lcompiler_rt > -lssp_nonshared;' .CURDIR=3D'/usr/src/lib/libc' .MAKE=3D'make' .OBJDIR=3D= '/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/arm64.aarch64/lib/= libc' .TARGETS=3D'all' > DESTDIR=3D'/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/arm64.= aarch64/tmp' > LD_LIBRARY_PATH=3D'' MACHINE=3D'arm64' MACHINE_ARCH=3D'aarch64' > MAKEOBJDIRPREFIX=3D'' MAKESYSPATH=3D'/usr/src/share/mk' > MAKE_VERSION=3D'20180222' > PATH=3D'/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/arm64.aar= ch64/tmp/legacy/usr/sbin:/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/us= r/src/arm64.aarch64/tmp/legacy/usr/bin:/usr/obj/cortexA53_xtoolchain-gcc/ar= m64.aarch64/usr/src/arm64.aarch64/tmp/legacy/bin:/usr/obj/cortexA53_xtoolch= ain-gcc/arm64.aarch64/usr/src/arm64.aarch64/tmp/usr/sbin:/usr/obj/cortexA53= _xtoolchain-gcc/arm64.aarch64/usr/src/arm64.aarch64/tmp/usr/bin:/sbin:/bin:= /usr/sbin:/usr/bin' > SRCTOP=3D'/usr/src' > OBJTOP=3D'/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/arm64.a= arch64' .MAKE.MAKEFILES=3D'/usr/src/share/mk/sys.mk /usr/src/share/mk/local= .sys.env.mk /usr/src/share/mk/src.sys.env.mk /root/src.configs/src.conf.cor= texA53-xtoolchain-gcc.amd64-host /usr/src/share/mk/bsd.mkopt.mk /usr/src/sh= are/mk/src.sys.obj.mk /usr/src/share/mk/auto.obj.mk /usr/src/share/mk/bsd.s= uffixes.mk /root/src.configs/make.conf /usr/src/share/mk/local.sys.mk /usr/= src/share/mk/src.sys.mk /dev/null /usr/src/lib/libc/Makefile /usr/src/share= /mk/src.opts.mk /usr/src/share/mk/bsd.own.mk /usr/src/share/mk/bsd.opts.mk = /usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/bsd.compiler.mk /usr/src/sha= re/mk/bsd.linker.mk /usr/src/lib/libc/aarch64/Makefile.inc /usr/src/lib/lib= c/db/Makefile.inc /usr/src/lib/libc/db/btree/Makefile.inc /usr/src/lib/libc= /db/db/Makefile.inc /usr/src/lib/libc/db/hash/Makefile.inc /usr/src/lib/lib= c/db/man/Makefile.inc /usr/src/lib/libc/db/mpool/Makefile.inc /usr/src/lib/= libc/db/recno/Makefile.inc /usr/src/lib/libc/compat-43/Makefile.inc /usr/sr= c/lib/libc/gdtoa/Makefile.inc /us > r/src/lib/libc/gen/Makefile.inc /usr/src/lib/libc/aarch64/gen/Makefile.in= c /usr/src/lib/libc/gmon/Makefile.inc /usr/src/lib/libc/iconv/Makefile.inc = /usr/src/lib/libc_nonshared/Makefile.iconv /usr/src/lib/libc/inet/Makefile.= inc /usr/src/lib/libc/isc/Makefile.inc /usr/src/lib/libc/locale/Makefile.in= c /usr/src/lib/libc/md/Makefile.inc /usr/src/lib/libc/nameser/Makefile.inc = /usr/src/lib/libc/net/Makefile.inc /usr/src/lib/libc/nls/Makefile.inc /usr/= src/lib/libc/posix1e/Makefile.inc /usr/src/lib/libc/regex/Makefile.inc /usr= /src/lib/libc/resolv/Makefile.inc /usr/src/lib/libc/stdio/Makefile.inc /usr= /src/lib/libc/stdlib/Makefile.inc /usr/src/lib/libc/stdlib/jemalloc/Makefil= e.inc /usr/src/lib/libc/stdtime/Makefile.inc /usr/src/lib/libc/string/Makef= ile.inc /usr/src/lib/libc/aarch64/string/Makefile.inc /usr/src/lib/libc/sys= /Makefile.inc /usr/src/sys/sys/syscall.mk /usr/src/lib/libc/aarch64/sys/Mak= efile.inc /usr/src/lib/libc/secure/Makefile.inc /usr/src/lib/libc/rpc/Makef= ile.inc /usr/src/lib/lib > c/uuid/Makefile.inc /usr/src/lib/libc/xdr/Makefile.inc /usr/src/lib/libc/= yp/Makefile.inc /usr/src/lib/libc/capability/Makefile.inc /usr/src/share/mk= /bsd.lib.mk /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/local.init.mk /= usr/src/share/mk/src.init.mk /usr/src/lib/libc/../Makefile.inc /usr/src/sha= re/mk/bsd.libnames.mk /usr/src/share/mk/src.libnames.mk /usr/src/share/mk/b= sd.symver.mk /usr/src/share/mk/bsd.nls.mk /usr/src/share/mk/bsd.files.mk /u= sr/src/share/mk/bsd.incs.mk /usr/src/share/mk/bsd.confs.mk /usr/src/share/m= k/bsd.links.mk /usr/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-ana= lyze.mk /usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk /usr/s= rc/share/mk/bsd.sys.mk' .PATH=3D'. /usr/src/lib/libc /usr/src/lib/libc/db/b= tree /usr/src/lib/libc/db/db /usr/src/lib/libc/db/hash /usr/src/lib/libc/db= /man /usr/src/lib/libc/db/mpool /usr/src/lib/libc/db/recno /usr/src/lib/lib= c/compat-43 /usr/src/lib/libc/gdtoa /usr/src/lib/libc/aarch64/gen /usr/src/= lib/libc/gen /usr/src/contrib/libc-pwcache /usr/src/contrib/libc-vis /usr/s= rc/lib/libc/gmon /usr/src/lib/libc/iconv /usr/src/lib/libc/inet /usr/src/li= b/libc/isc /usr/src/lib/libc/locale /usr/src/lib/libmd /usr/src/lib/libc/na= meser /usr/src/lib/libc/net /usr/src/lib/libc/nls /usr/src/lib/libc/posix1e= /usr/src/lib/libc/regex /usr/src/lib/libc/resolv /usr/src/lib/libc/stdio /= usr/src/lib/libc/stdlib /usr/src/lib/libc/stdlib/jemalloc /usr/src/lib/libc= /stdtime /usr/src/contrib/tzcode/stdtime /usr/src/lib/libc/aarch64/string /= usr/src/lib/libc/string /usr/src/sys/libkern /usr/src/contrib/cortex-string= s/src/aarch64 /usr/src/lib/libc/aarch64/sys /usr/src/lib/libc/sys /usr/src/= lib/libc/secure /usr/src/lib/libc/rpc /usr/src/li > b/libc/. /usr/src/lib/libc/uuid /usr/src/lib/libc/xdr /usr/src/lib/libc/y= p /usr/src/sys/kern /usr/src/lib/libc/capability' > 1 error >=20 >=20 > =3D=3D=3D > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" IIRC, I had to disable LTO plugin in binutils and this need to disable it was there for a while.=20 --=20 Alexander Kabaev --Sig_/0q2gf+JoULIeb6Raj+5ZdbV Content-Type: application/pgp-signature Content-Description: Цифровая подпись OpenPGP -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEExffZlZm2QeE8UVaRBxMimZJ5Ln4FAlrJR61fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEM1 RjdEOTk1OTlCNjQxRTEzQzUxNTY5MTA3MTMyMjk5OTI3OTJFN0UACgkQBxMimZJ5 Ln7WBA/8Dq0k23lfNGnqUtXX1VjEs6amJ9jaaflye2Zs/mV6Y8zxZR4GkKCKfLWc LA2spfZWUivMaFfMdBkvMDwSpdGJ0B6b01wYQKmGjx0omg4uIbOiY2yRhr6l+BJI bMmbjA5ysaanSRElwarph8yBPaeHX2D79tExQnghZq2pWsmUHgRQSZmpzvjaA+Yk ymMIGe1jAHYUIzRBwfWch3QS1fKr3oFD0rd+rOcBAJR1gFECVgs++mxkWj6eAgmj dEmng3Umu9hVxY5bFGmqnfoDZmrYYoAJ3PiXtul9l3eV2iOTlWep/ZT7hsMgDxR9 jU8ZcyEamOditroMcvpeUduBo3AQJ3sb7dX3/qsdUqhYTMgC4mEpWIv6SKY790uB ytr35ExxwclI0b2buzF4/zW4JNblCErgfmNyocfDOIbU7R65Xl3WEgkq1POGCWrX 2vc8ZhaSjCATUqlPJ1FeVfoEIuWu+WwBKXd9XfBdy7q7mX3x/1WS6r4IGMNFHh0U f3HnZfmdjzMMHU2t1cgZm9Nxj6I0kQohzCbhIyoO4iNoTMJswdPsWFvgFic//tfl 66QuD4MAJjdJY9cygNJ0StT4hOHSWb6jsqm9HWxRegQ5zCPQrNVQJ3TdpNxFpGIm hqln+MgHz+t7J4JZxPocOcOxHA8n+5tHvafKqQK9KY1dEgfwZHQ= =TP0S -----END PGP SIGNATURE----- --Sig_/0q2gf+JoULIeb6Raj+5ZdbV-- From owner-freebsd-toolchain@freebsd.org Sat Apr 7 22:43:21 2018 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DF954F8C0B6 for ; Sat, 7 Apr 2018 22:43:20 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 72FC66C079 for ; Sat, 7 Apr 2018 22:43:20 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: by mail-qk0-x232.google.com with SMTP id b198so5128873qkg.9 for ; Sat, 07 Apr 2018 15:43:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version; bh=G8IBmb8fuVW1OgPAU05U9ll73PdM5iFv+Y4NOSzVxaI=; b=eBI6bcDGfC3d8BmFCDAB0X9FAWwZekNwK29paEOrMszO50JtOdZUDkt87pQWBFAI55 eHTuNn6WTMA12jlzn/GRjppqjluSQ18fusxwMdo3hLqbAnnYi+8RUKCs+MlTZ+JmPLhO InQv04YUoT+zwbJSL3svRd0xZ9Cp/tj1lB2s5Bp8sU1GQ84mvkIpICQMn1T9lXw07wTj sI/8Lqx3f41hPNR+PU8Z5es/o0hyEx5vhO6P0yC+lGj0XaCOkv04aonJcG+sVrxIi0qh j0IqYlOUAo0guCC85ag/4ostQmnT/jVCHvyy9mV6lKI+Twyxa15xonJwaqzTsVPBcLkM EmZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version; bh=G8IBmb8fuVW1OgPAU05U9ll73PdM5iFv+Y4NOSzVxaI=; b=KPG+DF6/eKCB51bjYDLcYHP68XqmaGUy8kGKW7+Rd99HNwHMluiOSs7qno51VmvxKE 9xitnyx2DrlyB9LpOT0NexB7m0Eeuvgd7cjiV/0RTD/pFszisSm3WXZF//uKuZBwaV5D oFmkHSebO5igK94bCH0yDzkGKepSgKvqQ5l/BaxoaJ4rU2UQve2nzF/lLwVGw0QY7klR iCbqVdVV6vGtglnc9cpLHOzcC8uaBru+EPdQxl/35xCLopPizdOCqx/w5RUkjhVGxof8 YkPkTJDx/c7l86EXDaXCKfKPIUP2783uyeuAD6dtJtMWGpYY8QPYVfoj0nnQp+VYc4iz k2DQ== X-Gm-Message-State: ALQs6tCIHKVMfCOKPyDhhAYZpwLKJZnKDAq0vo8NWUEo1l/+OvKx14Vd f+v/CFCZ3nfBXEjm8KWrP/RsKzp5 X-Google-Smtp-Source: AIpwx4+2N4peUt0EnPX/YWF2Uuz89xvNGEY9UOzmH0GQMTJdl9ogNZXjcAwVW8WZYTUHVQKLAnnVJA== X-Received: by 10.55.200.193 with SMTP id t62mr44389093qkl.245.1523140999784; Sat, 07 Apr 2018 15:43:19 -0700 (PDT) Received: from kan ([2601:18f:802:4680:226:18ff:fe00:232e]) by smtp.gmail.com with ESMTPSA id c137sm10332643qkb.2.2018.04.07.15.43.18 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 07 Apr 2018 15:43:18 -0700 (PDT) Date: Sat, 7 Apr 2018 18:43:17 -0400 From: Alexander Kabaev To: Mark Millard via freebsd-toolchain Subject: Re: amd64-binutils file name structure for utils vs. for powerpc64-binutils and aarch64-binutils Message-ID: <20180407184317.3ab301e2@kan> In-Reply-To: References: X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/L5XJ8qET5OTur=m+KtUr=b5"; protocol="application/pgp-signature" X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2018 22:43:21 -0000 --Sig_/L5XJ8qET5OTur=m+KtUr=b5 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sat, 7 Apr 2018 15:30:08 -0700 Mark Millard via freebsd-toolchain wrote: > For: >=20 > # pkg info "*binutils" > aarch64-binutils-2.30_2,1 > amd64-binutils-2.30_2,1 > binutils-2.30_2,1 > powerpc64-binutils-2.30_2,1 >=20 > # svnlite info /usr/ports/ | grep "Re[plv]" > Relative URL: ^/head > Repository Root: svn://svn.freebsd.org/ports > Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 > Revision: 466704 > Last Changed Rev: 466704 >=20 > in a amd64 context . . . >=20 > amd64-binutils uses file naming that does not match the > patterns that aarch64-binutils and powerpc64-binutils > use. Using an example type of binutil for illustration > (in a 12.0 head context): >=20 > # find /usr/local/bin /usr/local/*freebsd* -name "*addr2line*" -print > /usr/local/bin/powerpc64-unknown-freebsd12.0-addr2line > /usr/local/bin/x86_64-freebsd-addr2line > /usr/local/bin/addr2line > /usr/local/bin/aarch64-unknown-freebsd12.0-addr2line >=20 > The differences involve the lack of: >=20 > -unknown > 12.0 >=20 > (Of course, plain binutils does not have such conventions.) >=20 > Is this expected/intended? >=20 >=20 > For reference: >=20 > # uname -apKU > FreeBSD FBSDFSSD 12.0-CURRENT FreeBSD 12.0-CURRENT r332181M amd64 > amd64 1200061 1200061 No, this is not indented, but that is how GCC/binutils configure works. When building 'native' config, it does not install full triple-prefixed binaries. I had to manually work around that in powerpc64-gcc, looks like bintuils need the same treatment.=20 --=20 Alexander Kabaev --Sig_/L5XJ8qET5OTur=m+KtUr=b5 Content-Type: application/pgp-signature Content-Description: Цифровая подпись OpenPGP -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEExffZlZm2QeE8UVaRBxMimZJ5Ln4FAlrJSYVfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEM1 RjdEOTk1OTlCNjQxRTEzQzUxNTY5MTA3MTMyMjk5OTI3OTJFN0UACgkQBxMimZJ5 Ln6a6RAAte90f16pAJwmUn6hQrhXdIQ4jZ+wpg535cSd8JO4zZahv365w0rrCciW QcwJX7/BaTF81+LiyuZwLyUnJfCbINoWyEUBtB/hHWWTMqJLWyUaxtnJDczwz/Mt 84EOvPsWS7W9PvNvfUDtCwQMKoXWYQw0aTNjnhDZCmsG1LBs8f/68kNZ+Sd4Ku3F Unjg23lbGLKBHM/D8HYhlNrFqS45zj4OtHqYh06/OeLJEKzG6hHNeRAjdR5YB4fW il9M378Eszw9/kVBf9/1Snj63pug2sPpFuWD3vqnaePCLk93P3Ojqn6s7uSfb18D qtmB16nEuSXwSvekRVsCsoaGzcN+iZrKyHE43+RGKX8fxggieWDUpg32Ifea9RKn iWGfx/zeN+1w0B25m7jibMsz3FuYSNgUPbj23uyo67t9L6Wlc0CJ9Tappq+oykAO fOCFLOxxECcLDPIvVNeECW1Ce34fhs0Xy9k9+BDs0b2UEP7Hljwnwly/xe5yfK4m RHykgjBd1lQkVWso4YB4Xx2eJyAfbBPyfM1EoHxAJZkyWr6FSwNmQ3rScf+O2kZP NtBpJH6qrfm57RXpEm61EBlGj8usO9TVeS3MskWIi8QdFp3IDsPz+1s8chOkHH7R 209uliDDWmWdybpAEpMLdLknQ3Bjlpn1dfLiE1KkK/ag1xzP6xA= =NVbo -----END PGP SIGNATURE----- --Sig_/L5XJ8qET5OTur=m+KtUr=b5-- From owner-freebsd-toolchain@freebsd.org Sat Apr 7 23:37:58 2018 Return-Path: Delivered-To: freebsd-toolchain@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 06B6BF8F148 for ; Sat, 7 Apr 2018 23:37:58 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 8D6C069A78 for ; Sat, 7 Apr 2018 23:37:57 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: by mail-qk0-x22a.google.com with SMTP id 132so5247657qkd.5 for ; Sat, 07 Apr 2018 16:37:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version; bh=RfFr5sOG28yPR/LL8Jh3CAAjDrhboQ9b2fy+7SMgDEM=; b=OgR/GCPOx36ZlRVvdEGw8USr+IRcUC/CXA1UbdexXxiyzTXdF50HYIlYc0aD5YOTng eaLN6hoGxzpgeo9TPsDGVTrBDVYeTnEb72zL0MRz2bfAQVN1vQrdWi/wb3ZXM4e8UmEU xRyF5MfbdMInMYVxjaloTv8+TYfM/I/DazBm5KxarIq3IN1TWf6ekddqBBjNAJyrsFGv ikwwvUVbsfXCqHtgr3F66KQFj29rHcQNWYqbf+njdNnIV10nRqaOWdG/Nnf4/2l7VtoK qdscPD84eiy7kQWIDyPb7qcCTgAIKm68SMBSoUkSbFJ13k6u4JG0V5f1FNXoHarXmoOe 5OJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version; bh=RfFr5sOG28yPR/LL8Jh3CAAjDrhboQ9b2fy+7SMgDEM=; b=G1eBpxknBjDgqFI8yVV8IcgFuKb0jp7fkpHTJMekXFA2DerkEq6o1FUq7ybJzTFe6y lZEcKqqQztsW4+LMzbSnZvRmrWk4NItbX+yIgspVNGolVYgkd/bsDXoqPAM+vxQ2NsQI 0i0I0Kc59geN/PH+rG9j0ecUwyrc/gSR7h+47eDmT2G6pDIdm5QgpOmp2/Af+o9OvvN5 FDt0cBU4FXv/9z2cml2jpyKCkAQGScutci6YGBe+vTOz8GUpd1dz0D0yw0Gxq+Xy2D+a ZRDngvB1Wo+KNhfA0fkU+pgZmzmKT945r4NO158r0/DYlbg99uJKGA3NDP3gP02dTdkL xpGg== X-Gm-Message-State: ALQs6tDI70TTQ9KeP1m6GNk2H43OYbV0U+Mh35K6RzLxjOnLLksZYXVM 5z7oYIcPYUNMFNqeNK1k+Zy452qf X-Google-Smtp-Source: AIpwx4+uuO6B9a/VuxTaUq4vrIj4B9TsTqmWj4rxmhJklQfQhfGM8yZ+ZCszYqvXAkNubqsvSxL+sA== X-Received: by 10.55.54.77 with SMTP id d74mr39393307qka.144.1523144276989; Sat, 07 Apr 2018 16:37:56 -0700 (PDT) Received: from kan ([2601:18f:802:4680:226:18ff:fe00:232e]) by smtp.gmail.com with ESMTPSA id g12sm11254154qtg.29.2018.04.07.16.37.55 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 07 Apr 2018 16:37:55 -0700 (PDT) Date: Sat, 7 Apr 2018 19:37:42 -0400 From: Alexander Kabaev To: Mark Millard via freebsd-toolchain Subject: Re: amd64-binutils file name structure for utils vs. for powerpc64-binutils and aarch64-binutils Message-ID: <20180407193742.1c6cd33d@kan> In-Reply-To: <20180407184317.3ab301e2@kan> References: <20180407184317.3ab301e2@kan> X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/P_3q=a9ChVQ3AqXYHnOFQEF"; protocol="application/pgp-signature" X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Apr 2018 23:37:58 -0000 --Sig_/P_3q=a9ChVQ3AqXYHnOFQEF Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sat, 7 Apr 2018 18:43:17 -0400 Alexander Kabaev wrote: Come to think of it, I am not sure I understand the problem. amd64-binutils installs "proper" x86_64-freebsd-prefixed binaries. Did you expect amd64-freebsd-* ? --=20 Alexander Kabaev --Sig_/P_3q=a9ChVQ3AqXYHnOFQEF Content-Type: application/pgp-signature Content-Description: Цифровая подпись OpenPGP -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEExffZlZm2QeE8UVaRBxMimZJ5Ln4FAlrJVkZfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEM1 RjdEOTk1OTlCNjQxRTEzQzUxNTY5MTA3MTMyMjk5OTI3OTJFN0UACgkQBxMimZJ5 Ln5WbQ//WJhECdXcFlZV3USXsvB6EII3RRGtpASHV2XGQ6pAAYmcLeqXN9qCFzlQ ZzsxKdOzPF0Fig3yHNfCrhUkQ3yD9UIAludpMU+6ZvOfjqN7YxgulXyhOtCOlxMe hIk7yv+AulUA4jM+iGCg3JQaS/vC6rUsFM3ek8fvkRMxix8cJNchKaVwZ3KlCE5O dUmyN+wPob5yRWlu8K/uOc8gcbw63yFGnNRe/yfxTALULWpVUWRC9ZEkUHCkYO+y 4CRQIcl+e4DU/oVj8XqbhgdgdfTMLDhnA/De7s5/vFMKVF2mIXfN+k5j2kmPofHS d7dNzsDXGuvnfZMntLOamM0mZ0JiYyhZIMQnzyNehqA9YYSOncWLtnwuIQjrjfjf Vic4nDOEJfMQjrU4J4m2mLKluPh4SvrNcVqIGkMWC87ID0him5i/Uo29lLieFo4v erp2eTnsjWR4h/Fu5KtcVfEEUI6buPtocyw2Rsv6k7sy/ir49vI1+htNATr2yotX 6fuC9Oj3CQZ32LGkIGEQLG+xPofo4RLXiJxEaS37jkN7K3oWkepBzDK5DfZxF73Z 4fcHeG0qRYwnAWXKJ2NGrLR2hvkuJCGZokHUPKGrWv5L6N+1Jmo81o3T6R5p7O4P ZX2QIXu0t/vwjivleyb+fAixH5t37HBCaoptyVHP92BlRxrusRc= =/N5E -----END PGP SIGNATURE----- --Sig_/P_3q=a9ChVQ3AqXYHnOFQEF--