FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=releng%2F11.2 2017-10-07T18:46:50Z 2017-10-07T18:46:50Z Enji Cooper ngie@FreeBSD.org 2017-10-07T18:46:50Z urn:sha1:17b66b68c3d4fa66ca57504aeccc8da7c3cfc405 Adjust r322633 to only apply to libexec/rtld-elf, and not usr.bin/ldd, when running build32/install32 This unbreaks installing usr.bin/ldd as ldd32 when NO_RTLD is defined. MFC with: r322633 2017-09-08T04:33:24Z Enji Cooper ngie@FreeBSD.org 2017-09-08T04:33:24Z urn:sha1:e3e993b10736449ebc7eebd4a112c029b26b908c Honor NO_RTLD for rtld-elf, similar to what's done in libexec/Makefile, with libexec/rtld-elf/... for MK_{LIB32,LIBSOFT}. 2017-08-12T17:50:22Z Dimitry Andric dim@FreeBSD.org 2017-08-12T17:50:22Z urn:sha1:a3059dd93ecb90d5cd6de1b1c6c198a9e3e49f2a Don't use libc++ when cross-building for gcc arches Since we imported clang 5.0.0, the version check in Makefile.inc1 which checks whether to use libc++ fires even when the compiler for the target architecture is gcc 4.2.1. This is because only X_COMPILER_VERSION is checked. Also check X_COMPILER_TYPE, so it will only use libc++ when an external gcc toolchain is used. Reviewed by: emaste, rpokala Differential Revision: https://reviews.freebsd.org/D11776 MFC r322170: Follow-up to r321684 (Don't use libc++ when cross-building for gcc arches), and handle two more cases where libc++ includes could be incorrectly enabled, in case the host compiler is clang 5.0.0, and the target (cross) compiler is gcc 4.2.1. Noted by: bdrewery 2017-07-26T23:18:14Z Ed Maste emaste@FreeBSD.org 2017-07-26T23:18:14Z urn:sha1:2ad90119ea9dc83c194b2f192d87e82366ce3e61 An attempt to build mips64 using external toolchain failed as it tried to use the host amd64 nm. 2017-04-28T17:54:45Z Bryan Drewery bdrewery@FreeBSD.org 2017-04-28T17:54:45Z urn:sha1:672a99fa6cc1392e0dd3ea5c16a02f2ffc2d8414 META_MODE: Fix build-tools still sometimes rebuilding during target build. 2016-07-27T05:38:09Z Bryan Drewery bdrewery@FreeBSD.org 2016-07-27T05:38:09Z urn:sha1:20528c390f9f1999f88d3c7eefb8ef97158e3a9e Don't disable binutils/elftoolchain bootstrapping with external compiler. Approved by: re (kib) 2016-06-29T01:50:30Z Bryan Drewery bdrewery@FreeBSD.org 2016-06-29T01:50:30Z urn:sha1:48413367ef81450140b6a3a8fb2db6807100b862 As the XXX notes, these should really be checking MK_GNUCXX since there is already a version check in share/mk/src.opts.mk to disable it. Fixing that here is more complex though. This could also be using X_COMPILER_FEATURES but uses X_COMPILER_VERSION to keep in sync with the src.opts.mk logic. Tested by: andreast Sponsored by: EMC / Isilon Storage Division Approved by: re (gjb) 2016-06-15T23:58:03Z Bryan Drewery bdrewery@FreeBSD.org 2016-06-15T23:58:03Z urn:sha1:07394091841ffac046b44b946254f6f8beb31adc - This was broken by r300350 and r300885. - Add some comments around the external GCC logic since it is spread out and in need of some cleanup. - The problem was that X_COMPILER_TYPE is always defined from CC->XCC's default, so if /usr/bin/cc is GCC (as it is on native powerpc64) then X_COMPILER_TYPE was getting GCC and triggering the external logic in Makefile.libcompat. It was intended to always provide -isystem with GCC since --sysroot is used into the lib32 sysroot which won't modify the header path without the -isystem. The use of the libc++/std=c++11 override was only intended to be used for external compilers though (more accurately GCC 4.8+ but that's a separate assumption to cleanup). Apply the same logic from Makefile.inc1 to Makefile.libcompat to only add the libc++ override when needed for external compilers. Pointyhat to: bdrewery Tested with: native ppc64 (swills), universe, ppc64 xtoolchain, amd64 xtoolchain, sparc64 cross-build of ppc64 (host GCC 4.2) Reported by: andreast, swills Approved by: re (gjb) Sponsored by: EMC / Isilon Storage Division 2016-06-09T17:03:03Z Ed Maste emaste@FreeBSD.org 2016-06-09T17:03:03Z urn:sha1:dfaedbb2c93c7f4c9f9b968918956111e2bd821c -Y is an uncommon linker option that is rather similar to -L. In discussion with Peter it seems early amd64 development might have required the -Y-specific behaviour, but it is no longer necessary. Switch to -L which is more widely supported and much more commonly used, to make it easier to link the FreeBSD base system with linkers other than ld.bfd. Submitted by: Rafael Ávila de Espíndola Differential Revision: https://reviews.freebsd.org/D6681 2016-05-29T06:20:36Z Bryan Drewery bdrewery@FreeBSD.org 2016-05-29T06:20:36Z urn:sha1:76c5029cdfe12a83a99cb0e64680b228199cee12 This is the same as done for the native build in r300770 to ensure that the libc++ build reads from SYSROOT/usr/include/c++/v1 before reading from SYSROOT/usr/include.