Date: Mon, 9 Apr 2018 20:58:29 -0400 From: Alexander Kabaev <kabaev@gmail.com> To: John Baldwin <jhb@freebsd.org> Cc: Mark Millard <marklmi26-fbsd@yahoo.com>, freebsd-toolchain@freebsd.org Subject: Re: amd64-binutils file name structure for utils vs. for powerpc64-binutils and aarch64-binutils Message-ID: <20180409205829.37a11479@kan> In-Reply-To: <1666724.ZHi5oRvF8N@ralph.baldwin.cx> References: <D9BAEC2B-AED4-4031-8B60-658660DBCF28@yahoo.com> <4410009D-E857-4BB0-B865-9294D24187F5@yahoo.com> <20180407221447.63e016cc@kan> <1666724.ZHi5oRvF8N@ralph.baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_/.eJVy14DIec8PkP/pZF4nDR Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 09 Apr 2018 12:27:18 -0700 John Baldwin <jhb@freebsd.org> wrote: > On Saturday, April 07, 2018 10:14:47 PM Alexander Kabaev wrote: > > On Sat, 7 Apr 2018 17:01:30 -0700 > > Mark Millard <marklmi26-fbsd@yahoo.com> wrote: > > =20 > > > On 2018-Apr-7, at 4:37 PM, Alexander Kabaev <kabaev at gmail.com> > > > wrote: > > > =20 > > > > On Sat, 7 Apr 2018 18:43:17 -0400 > > > > Alexander Kabaev <kabaev@gmail.com> wrote: > > > >=20 > > > > 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 > > >=20 > > > My understanding was that cross-build tools are now supposed > > > to have the -unknown and the os version (12.0 here) even > > > when the cross-build is targeting the same environment as the > > > host environment. In other words: that it is not supposed to > > > be the same as plain binutils for the host but as-if it was > > > from a different architecture. > > >=20 > > > But I was checking my understanding. In part because it used > > > to be that, for example, on amd64 the aarch64-binutils also > > > omitted the -unknown and 12.0 but now has them. I just had > > > to update my environment's references to such for that. (This > > > was not a self-hosted cross-build context and it changed.) > > >=20 > > > Also, there is a recent check-in, -r466699 , for ports that, > > > in part, says: > > >=20 > > > Log: > > > Fix two more issues with r465416. > > > =20 > > > - Force build of a cross-compiler by defining > > > CROSS_DIRECTORY_STRUCTURE in CFLAGS even if the build host matches > > > the build target. This fixes such a cross compiler to not > > > include /usr/local/lib in its default library path (e.g. amd64-gcc > > > when built on amd64). > > >=20 > > >=20 > > >=20 > > > But that was for powerpc64-gcc, not powerpc64-binutils (for > > > example). I do not know for sure if similar points should also > > > apply to *-binutils ports. So, again, I was checking. > > >=20 > > > (I might have just got involved between already-made and other > > > pending updates for all I know.) > > >=20 > > > =20 > >=20 > > Since I am not the maintainer of binutils ports, I missed wholesale > > rename. I suspect something like the patch below will make > > amd64-binutils follow the convention: > >=20 > > P164: https://reviews.freebsd.org/P164 =20 >=20 > Huh, I didn't need this change when using amd64-xtoolchain-gcc, but it > does seem correct. I wonder if you will need to fix the > amd64-xtoolchain-gcc package as well. >=20 > In general I actually don't like having the OS version present as the > xtoolchain packages should not be version-specific (that is, I can use > mips-gcc to compile 10, 11, or 12), and even if it was, it the > _host's_ OS version is not necessarily the OS version of the target I > want to build. However, GCC's FreeBSD specific bits currently require > a major version for FBSD_MAJOR, and I had to resort to the hack in > the commit above to set CROSS_DIRECTORY_STRUCTURE explicitly. If we > were to drop OSREL from the GCC and BU targets then the normal cross > logic in GCC would work such that I wouldn't have needed the hack. >=20 > We could perhaps patch GCC to assume that if FBSD_MAJOR is not set it > should assume some minimum default version (I think any value >=3D 6 is > treated the same). We could then drop OSREL from the external > toolchain ports (binutils and GCC) which I would prefer. >=20 > --=20 > John Baldwin OSREL is an artifact of old times where we had wildly different specs. This is not true anymore, so deorbiting the OSREL suffix makes sense. For the time being, having binutils with same prefox as corresponding GCC is actually a good thing. --=20 Alexander Kabaev --Sig_/.eJVy14DIec8PkP/pZF4nDR Content-Type: application/pgp-signature Content-Description: Цифровая подпись OpenPGP -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEExffZlZm2QeE8UVaRBxMimZJ5Ln4FAlrMDDZfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEM1 RjdEOTk1OTlCNjQxRTEzQzUxNTY5MTA3MTMyMjk5OTI3OTJFN0UACgkQBxMimZJ5 Ln7I+hAAnz74ijZsiUFV9hdKVeTjfA8Zi+65nv4RGrk0koNfK3Mn4rtf2S4xVUTp LqnSWxgOhEdn4fYCD/rGLAUJ2hWZSMdr1+0oDWHvR150Iydr9HCGFXpJbmiobxoQ VbwTiKk036U9I2yUd8Np/cQMB0f/TUAkxp26o6ZXwLC0p6UYnVMB6fKS6orVW8CW X/jlEElVcwtgETENmaIPnaL5Mp7JzvumD8CZR9JlDPtIYrtk2NDslvNKJAlbYr5e tnf98AaVmCyTrd0rr2sznsStCxmuWCHEVZyyZz2AfrrRPFvtHVRsSSUa9pZgxvP+ y/NX/e6vnC8DqDOa8SzBBWkVOB5OWNvliNn4w8YslMBIs9S2RlwVlNASYCzyX+RS uySrFE+mdr+9fzIqC1BIHSlw54WQ55p9qVHjG1kukAOekVF6/eeK9XAvT9IC7Y/2 iyfU7fDK8LYHFQwlCDOIyQYw3i645g0Mguj4Av1lxqCsOW4Fj60CF08WBvuiYb8n rt2G8yn63s8qMh8Etz9bJh/cuZQXKwMgdwPDnIc8oIE1PZSbzRI5mh965RhgZIi1 uPWFQ4idkmUqmQYzZrylrScvR9m2Ckc18g1I26B5pFRydvzfmvtIXu8N/i7M/YJP 0xX8oC+Q9caLQ1VNIe8zXzr6yT49oFti2kzlTIK5cGxL0xYgfnU= =Xltm -----END PGP SIGNATURE----- --Sig_/.eJVy14DIec8PkP/pZF4nDR--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180409205829.37a11479>