[Bug bootstrap/87030] GCC fails to build with Xcode 10, attempting an impossible multilib build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87030 Iain Sandoe changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #27 from Iain Sandoe --- fixed on open branches.
[Bug bootstrap/87030] GCC fails to build with Xcode 10, attempting an impossible multilib build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87030 --- Comment #26 from Iain Sandoe --- Author: iains Date: Thu Sep 5 19:14:35 2019 New Revision: 275429 URL: https://gcc.gnu.org/viewcvs?rev=275429=gcc=rev Log: [Darwin] Fix PR87030 and tidy config fragments. This is about 32/64b host and multilib support across the range of Darwin systems. Prior to Darwin8 (OS X 10.4), the toolchains support only PowerPC and only 32b. On Darwin8 it is possible to target a 64b multilib, but with support limited to a few of the main libraries on the system (not a recommended configuration). >From Darwin9 to Darwin17 (OSX 10.5 to 10.13) it is possible to have either 32 or 64b hosted toolchains, with support for a 64 or 32b multilib respectively. On Darwin9 the kernel is 32b, but with support for 64b executables, so it's conventional to build a 32b host toolchain supporting a 64b multilib. However this is not enforced (merely a convention). There is also some platform hardware supporting Darwin10/11 which is only 32b and for which the same situation applies. However, from Darwin10 to Darwin17, the majority of platform hardware supports a 64b kernel and it's conventional to build a 64b host toolchain with support for a 32b multilib. On/from Darwin18 (OS X 10.14), the development headers (in the SDK) no longer expose the interfaces for the 32b multilib support (although sufficient runtime support remains installed that the testsuite can be run for a 32b multilib). The PR is raised against this latter situation since the absence of exposed interfaces causes a 'default' bootstrap fail regardless of the availability of the runtimes. Given the number of permutations, I felt it warranted a general solution, especially since the current scheme of target headers and t-make fragments has become somewhat messy. The changes here enforce the single 32b PowerPC multilib for Darwin < 8 and the single X86 64b multilib for Darwin >= 18. This means that there is no longer any need to configure Darwin18+ '--disable-multilib', but also that if you want to use the ability to continue to test the compiler's 32b multilib there, you need to make a configuration targeting an earlier OS version (and using the SDK from that). 2019-09-05 Iain Sandoe Backport from mainline 2019-07-24 Iain Sandoe PR bootstrap/87030 * config/i386/darwin.h (REAL_LIBGCC_SPEC): Revert change from r273749. PR bootstrap/87030 * config/i386/darwin.h (REAL_LIBGCC_SPEC): Move from here... * config/i386/darwin32-biarch.h .. to here. * config/i386/darwin64-biarch.h: Adjust comments. * config/rs6000/darwin32-biarch.h: Likewise. * config/rs6000/darwin64-biarch.h: Likewise. * config.gcc: Missed commit from r273746 (*-*-darwin*): Don't include CPU t-darwin here. (i[34567]86-*-darwin*): Adjust to use biarch files. Produce an error message if i686-darwin configuration is attempted for Darwin >= 18. Backport from mainline 2019-07-23 Iain Sandoe PR bootstrap/87030 * config.gcc (*-*-darwin*): Don't include CPU t-darwin here. (i[34567]86-*-darwin*): Adjust to use biarch files. Produce an error message if i686-darwin configuration is attempted for Darwin >= 18. (x86_64-*-darwin*): Switch to single multilib for Darwin >= 18. (powerpc-*-darwin*): Use biarch files where needed. (powerpc64-*-darwin*): Likewise. * config/i386/darwin.h (REAL_LIBGCC_SPEC): Move to new biarch file. (DARWIN_ARCH_SPEC, DARWIN_SUBARCH_SPEC): Revise for default single arch case. * config/i386/darwin32-biarch.h: New. * config/i386/darwin64.h: Rename. * gcc/config/i386/darwin64-biarch.h: To this. * config/i386/t-darwin: Rename. * gcc/config/i386/t-darwin32-biarch: To this. * config/i386/t-darwin64: Rename. * gcc/config/i386/t-darwin64-biarch: To this. * config/rs6000/darwin32-biarch.h: New. * config/rs6000/darwin64.h: Rename. * config/rs6000/darwin64-biarch.h: To this. (DARWIN_ARCH_SPEC, DARWIN_SUBARCH_SPEC): Revise for default single arch case. * config/rs6000/t-darwin8: Rename. * config/rs6000/t-darwin32-biarch: To this. * config/rs6000/t-darwin64 Rename. * config/rs6000/t-darwin64-biarch: To this. Added: branches/gcc-7-branch/gcc/config/i386/darwin32-biarch.h branches/gcc-7-branch/gcc/config/i386/darwin64-biarch.h branches/gcc-7-branch/gcc/config/i386/t-darwin32-biarch branches/gcc-7-branch/gcc/config/i386/t-darwin64-biarch branches/gcc-7-branch/gcc/config/rs6000/darwin32-biarch.h branches/gcc-7-branch/gcc/config/rs6000/darwin64-biarch.h branches/gcc-7-branch/gcc/config/rs6000/t-darwin32-biarch branches/gcc-7-branch/gcc/config/rs6000/t-darwin64-biarch Removed: branches/gcc-7-branch/gcc/config/i386/darwin64.h
[Bug bootstrap/87030] GCC fails to build with Xcode 10, attempting an impossible multilib build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87030 Iain Sandoe changed: What|Removed |Added Target Milestone|8.4 |7.5 --- Comment #25 from Iain Sandoe --- fixed for 8.4 - the problem exists on earlier branches too, so will backport for 7.5 if time permits.
[Bug bootstrap/87030] GCC fails to build with Xcode 10, attempting an impossible multilib build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87030 --- Comment #24 from Iain Sandoe --- Author: iains Date: Thu Aug 29 19:26:45 2019 New Revision: 275052 URL: https://gcc.gnu.org/viewcvs?rev=275052=gcc=rev Log: [Darwin] Fix PR87030 and tidy config fragments. This is about 32/64b host and multilib support across the range of Darwin systems. Prior to Darwin8 (OS X 10.4), the toolchains support only PowerPC and only 32b. On Darwin8 it is possible to target a 64b multilib, but with support limited to a few of the main libraries on the system (not a recommended configuration). >From Darwin9 to Darwin17 (OSX 10.5 to 10.13) it is possible to have either 32 or 64b hosted toolchains, with support for a 64 or 32b multilib respectively. On Darwin9 the kernel is 32b, but with support for 64b executables, so it's conventional to build a 32b host toolchain supporting a 64b multilib. However this is not enforced (merely a convention). There is also some platform hardware supporting Darwin10/11 which is only 32b and for which the same situation applies. However, from Darwin10 to Darwin17, the majority of platform hardware supports a 64b kernel and it's conventional to build a 64b host toolchain with support for a 32b multilib. On/from Darwin18 (OS X 10.14), the development headers (in the SDK) no longer expose the interfaces for the 32b multilib support (although sufficient runtime support remains installed that the testsuite can be run for a 32b multilib). The PR is raised against this latter situation since the absence of exposed interfaces causes a 'default' bootstrap fail regardless of the availability of the runtimes. Given the number of permutations, I felt it warranted a general solution, especially since the current scheme of target headers and t-make fragments has become somewhat messy. The changes here enforce the single 32b PowerPC multilib for Darwin < 8 and the single X86 64b multilib for Darwin >= 18. This means that there is no longer any need to configure Darwin18+ '--disable-multilib', but also that if you want to use the ability to continue to test the compiler's 32b multilib there, you need to make a configuration targeting an earlier OS version (and using the SDK from that). 2019-08-29 Iain Sandoe Backport from mainline 2019-07-24 Iain Sandoe PR bootstrap/87030 * config/i386/darwin.h (REAL_LIBGCC_SPEC): Revert change from r273749. PR bootstrap/87030 * config/i386/darwin.h (REAL_LIBGCC_SPEC): Move from here... * config/i386/darwin32-biarch.h .. to here. * config/i386/darwin64-biarch.h: Adjust comments. * config/rs6000/darwin32-biarch.h: Likewise. * config/rs6000/darwin64-biarch.h: Likewise. * config.gcc: Missed commit from r273746 (*-*-darwin*): Don't include CPU t-darwin here. (i[34567]86-*-darwin*): Adjust to use biarch files. Produce an error message if i686-darwin configuration is attempted for Darwin >= 18. Backport from mainline 2019-07-23 Iain Sandoe PR bootstrap/87030 * config.gcc (*-*-darwin*): Don't include CPU t-darwin here. (i[34567]86-*-darwin*): Adjust to use biarch files. Produce an error message if i686-darwin configuration is attempted for Darwin >= 18. (x86_64-*-darwin*): Switch to single multilib for Darwin >= 18. (powerpc-*-darwin*): Use biarch files where needed. (powerpc64-*-darwin*): Likewise. * config/i386/darwin.h (REAL_LIBGCC_SPEC): Move to new biarch file. (DARWIN_ARCH_SPEC, DARWIN_SUBARCH_SPEC): Revise for default single arch case. * config/i386/darwin32-biarch.h: New. * config/i386/darwin64.h: Rename. * gcc/config/i386/darwin64-biarch.h: To this. * config/i386/t-darwin: Rename. * gcc/config/i386/t-darwin32-biarch: To this. * config/i386/t-darwin64: Rename. * gcc/config/i386/t-darwin64-biarch: To this. * config/rs6000/darwin32-biarch.h: New. * config/rs6000/darwin64.h: Rename. * config/rs6000/darwin64-biarch.h: To this. (DARWIN_ARCH_SPEC, DARWIN_SUBARCH_SPEC): Revise for default single arch case. * config/rs6000/t-darwin8: Rename. * config/rs6000/t-darwin32-biarch: To this. * config/rs6000/t-darwin64 Rename. * config/rs6000/t-darwin64-biarch: To this. Added: branches/gcc-8-branch/gcc/config/i386/darwin32-biarch.h branches/gcc-8-branch/gcc/config/i386/darwin64-biarch.h branches/gcc-8-branch/gcc/config/i386/t-darwin32-biarch branches/gcc-8-branch/gcc/config/i386/t-darwin64-biarch branches/gcc-8-branch/gcc/config/rs6000/darwin32-biarch.h branches/gcc-8-branch/gcc/config/rs6000/darwin64-biarch.h branches/gcc-8-branch/gcc/config/rs6000/t-darwin32-biarch branches/gcc-8-branch/gcc/config/rs6000/t-darwin64-biarch Removed: branches/gcc-8-branch/gcc/config/i386/darwin64.h
[Bug bootstrap/87030] GCC fails to build with Xcode 10, attempting an impossible multilib build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87030 --- Comment #23 from Iain Sandoe --- fixed on trunk and for 9.2
[Bug bootstrap/87030] GCC fails to build with Xcode 10, attempting an impossible multilib build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87030 --- Comment #22 from Iain Sandoe --- Author: iains Date: Sat Aug 3 20:16:22 2019 New Revision: 274049 URL: https://gcc.gnu.org/viewcvs?rev=274049=gcc=rev Log: Darwin, backport fix for PR87030 273746 , 273749, 273768 [Darwin] Fix PR87030 and tidy config fragments. This is about 32/64b host and multilib support across the range of Darwin systems. Prior to Darwin8 (OS X 10.4), the toolchains support only PowerPC and only 32b. On Darwin8 it is possible to target a 64b multilib, but with support limited to a few of the main libraries on the system (not a recommended configuration). >From Darwin9 to Darwin17 (OSX 10.5 to 10.13) it is possible to have either 32 or 64b hosted toolchains, with support for a 64 or 32b multilib respectively. On Darwin9 the kernel is 32b, but with support for 64b executables, so it's conventional to build a 32b host toolchain supporting a 64b multilib. However this is not enforced (merely a convention). There is also some platform hardware supporting Darwin10/11 which is only 32b and for which the same situation applies. However, from Darwin10 to Darwin17, the majority of platform hardware supports a 64b kernel and it's conventional to build a 64b host toolchain with support for a 32b multilib. On/from Darwin18 (OS X 10.14), the development headers (in the SDK) no longer expose the interfaces for the 32b multilib support (although sufficient runtime support remains installed that the testsuite can be run for a 32b multilib). The PR is raised against this latter situation since the absence of exposed interfaces causes a 'default' bootstrap fail regardless of the availability of the runtimes. Given the number of permutations, I felt it warranted a general solution, especially since the current scheme of target headers and t-make fragments has become somewhat messy. The changes here enforce the single 32b PowerPC multilib for Darwin < 8 and the single X86 64b multilib for Darwin >= 18. This means that there is no longer any need to configure Darwin18+ '--disable-multilib', but also that if you want to use the ability to continue to test the compiler's 32b multilib there, you need to make a configuration targeting an earlier OS version (and using the SDK from that). 2019-08-03 Iain Sandoe Backport from mainline 2019-07-24 Iain Sandoe PR bootstrap/87030 * config/i386/darwin.h (REAL_LIBGCC_SPEC): Revert change from r273749. PR bootstrap/87030 * config/i386/darwin.h (REAL_LIBGCC_SPEC): Move from here... * config/i386/darwin32-biarch.h .. to here. * config/i386/darwin64-biarch.h: Adjust comments. * config/rs6000/darwin32-biarch.h: Likewise. * config/rs6000/darwin64-biarch.h: Likewise. * config.gcc: Missed commit from r273746 (*-*-darwin*): Don't include CPU t-darwin here. (i[34567]86-*-darwin*): Adjust to use biarch files. Produce an error message if i686-darwin configuration is attempted for Darwin >= 18. Backport from mainline 2019-07-23 Iain Sandoe PR bootstrap/87030 * config.gcc (*-*-darwin*): Don't include CPU t-darwin here. (i[34567]86-*-darwin*): Adjust to use biarch files. Produce an error message if i686-darwin configuration is attempted for Darwin >= 18. (x86_64-*-darwin*): Switch to single multilib for Darwin >= 18. (powerpc-*-darwin*): Use biarch files where needed. (powerpc64-*-darwin*): Likewise. * config/i386/darwin.h (REAL_LIBGCC_SPEC): Move to new biarch file. (DARWIN_ARCH_SPEC, DARWIN_SUBARCH_SPEC): Revise for default single arch case. * config/i386/darwin32-biarch.h: New. * config/i386/darwin64.h: Rename. * gcc/config/i386/darwin64-biarch.h: To this. * config/i386/t-darwin: Rename. * gcc/config/i386/t-darwin32-biarch: To this. * config/i386/t-darwin64: Rename. * gcc/config/i386/t-darwin64-biarch: To this. * config/rs6000/darwin32-biarch.h: New. * config/rs6000/darwin64.h: Rename. * config/rs6000/darwin64-biarch.h: To this. (DARWIN_ARCH_SPEC, DARWIN_SUBARCH_SPEC): Revise for default single arch case. * config/rs6000/t-darwin8: Rename. * config/rs6000/t-darwin32-biarch: To this. * config/rs6000/t-darwin64 Rename. * config/rs6000/t-darwin64-biarch: To this. Added: branches/gcc-9-branch/gcc/config/i386/darwin32-biarch.h branches/gcc-9-branch/gcc/config/i386/darwin64-biarch.h branches/gcc-9-branch/gcc/config/i386/t-darwin32-biarch branches/gcc-9-branch/gcc/config/i386/t-darwin64-biarch branches/gcc-9-branch/gcc/config/rs6000/darwin32-biarch.h branches/gcc-9-branch/gcc/config/rs6000/darwin64-biarch.h branches/gcc-9-branch/gcc/config/rs6000/t-darwin32-biarch branches/gcc-9-branch/gcc/config/rs6000/t-darwin64-biarch
[Bug bootstrap/87030] GCC fails to build with Xcode 10, attempting an impossible multilib build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87030 --- Comment #21 from Iain Sandoe --- Author: iains Date: Wed Jul 24 19:59:22 2019 New Revision: 273768 URL: https://gcc.gnu.org/viewcvs?rev=273768=gcc=rev Log: [Darwin] Partial reversion of 273749. We still need to cater for pr80556, for the single-arch case. 2019-07-24 Iain Sandoe gcc/ PR bootstrap/87030 * config/i386/darwin.h (REAL_LIBGCC_SPEC): Revert r273749. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/darwin.h
[Bug bootstrap/87030] GCC fails to build with Xcode 10, attempting an impossible multilib build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87030 --- Comment #20 from Iain Sandoe --- Author: iains Date: Tue Jul 23 23:20:31 2019 New Revision: 273749 URL: https://gcc.gnu.org/viewcvs?rev=273749=gcc=rev Log: [Darwin] Fix PR87030 add missed commit hunks. Messed up the commit, and missed changes to gcc/config.gcc and to the comments in some of the headers. 2019-07-24 Iain Sandoe gcc/ PR bootstrap/87030 * config/i386/darwin.h (REAL_LIBGCC_SPEC): Move from here... * config/i386/darwin32-biarch.h .. to here. * config/i386/darwin64-biarch.h: Adjust comments. * config/rs6000/darwin32-biarch.h: Likewise. * config/rs6000/darwin64-biarch.h: Likewise. * config.gcc: Missed commit from r273746 (*-*-darwin*): Don't include CPU t-darwin here. (i[34567]86-*-darwin*): Adjust to use biarch files. Produce an error message if i686-darwin configuration is attempted for Darwin >= 18. Modified: trunk/gcc/ChangeLog trunk/gcc/config.gcc trunk/gcc/config/i386/darwin.h trunk/gcc/config/i386/darwin32-biarch.h trunk/gcc/config/i386/darwin64-biarch.h trunk/gcc/config/rs6000/darwin32-biarch.h trunk/gcc/config/rs6000/darwin64-biarch.h
[Bug bootstrap/87030] GCC fails to build with Xcode 10, attempting an impossible multilib build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87030 --- Comment #19 from Iain Sandoe --- Author: iains Date: Tue Jul 23 20:31:26 2019 New Revision: 273746 URL: https://gcc.gnu.org/viewcvs?rev=273746=gcc=rev Log: [Darwin] Fix PR87030 and tidy config fragments. This is about 32/64b host and multilib support across the range of Darwin systems. Prior to Darwin8 (OS X 10.4), the toolchains support only PowerPC and only 32b. On Darwin8 it is possible to target a 64b multilib, but with support limited to a few of the main libraries on the system (not a recommended configuration). >From Darwin9 to Darwin17 (OSX 10.5 to 10.13) it is possible to have either 32 or 64b hosted toolchains, with support for a 64 or 32b multilib respectively. On Darwin9 the kernel is 32b, but with support for 64b executables, so it's conventional to build a 32b host toolchain supporting a 64b multilib. However this is not enforced (merely a convention). There is also some platform hardware supporting Darwin10/11 which is only 32b and for which the same situation applies. However, from Darwin10 to Darwin17, the majority of platform hardware supports a 64b kernel and it's conventional to build a 64b host toolchain with support for a 32b multilib. On/from Darwin18 (OS X 10.14), the development headers (in the SDK) no longer expose the interfaces for the 32b multilib support (although sufficient runtime support remains installed that the testsuite can be run for a 32b multilib). The PR is raised against this latter situation since the absence of exposed interfaces causes a 'default' bootstrap fail regardless of the availability of the runtimes. Given the number of permutations, I felt it warranted a general solution, especially since the current scheme of target headers and t-make fragments has become somewhat messy. The changes here enforce the single 32b PowerPC multilib for Darwin < 8 and the single X86 64b multilib for Darwin >= 18. This means that there is no longer any need to configure Darwin18+ '--disable-multilib', but also that if you want to use the ability to continue to test the compiler's 32b multilib there, you need to make a configuration targeting an earlier OS version (and using the SDK from that). gcc/ PR bootstrap/87030 * config.gcc (*-*-darwin*): Don't include CPU t-darwin here. (i[34567]86-*-darwin*): Adjust to use biarch files. Produce an error message if i686-darwin configuration is attempted for Darwin >= 18. (x86_64-*-darwin*): Switch to single multilib for Darwin >= 18. (powerpc-*-darwin*): Use biarch files where needed. (powerpc64-*-darwin*): Likewise. * config/i386/darwin.h (REAL_LIBGCC_SPEC): Move to new biarch file. (DARWIN_ARCH_SPEC, DARWIN_SUBARCH_SPEC): Revise for default single arch case. * config/i386/darwin32-biarch.h: New. * config/i386/darwin64.h: Rename. * gcc/config/i386/darwin64-biarch.h: To this. * config/i386/t-darwin: Rename. * gcc/config/i386/t-darwin32-biarch: To this. * config/i386/t-darwin64: Rename. * gcc/config/i386/t-darwin64-biarch: To this. * config/rs6000/darwin32-biarch.h: New. * config/rs6000/darwin64.h: Rename. * config/rs6000/darwin64-biarch.h: To this. (DARWIN_ARCH_SPEC, DARWIN_SUBARCH_SPEC): Revise for default single arch case. * config/rs6000/t-darwin8: Rename. * config/rs6000/t-darwin32-biarch: To this. * config/rs6000/t-darwin64 Rename. * config/rs6000/t-darwin64-biarch: To this. Added: trunk/gcc/config/i386/darwin32-biarch.h trunk/gcc/config/i386/darwin64-biarch.h trunk/gcc/config/i386/t-darwin32-biarch trunk/gcc/config/i386/t-darwin64-biarch trunk/gcc/config/rs6000/darwin32-biarch.h trunk/gcc/config/rs6000/darwin64-biarch.h trunk/gcc/config/rs6000/t-darwin32-biarch trunk/gcc/config/rs6000/t-darwin64-biarch Removed: trunk/gcc/config/i386/darwin64.h trunk/gcc/config/i386/t-darwin trunk/gcc/config/i386/t-darwin64 trunk/gcc/config/rs6000/darwin64.h trunk/gcc/config/rs6000/t-darwin64 trunk/gcc/config/rs6000/t-darwin8 Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/darwin.h trunk/gcc/config/rs6000/darwin.h
[Bug bootstrap/87030] GCC fails to build with Xcode 10, attempting an impossible multilib build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87030 --- Comment #18 from Eric Gallager --- (In reply to Iain Sandoe from comment #17) > I have a patch series to fix this - but it's not really appropriate this > late in stage 4. So plan is to fix in early 10 stage 1 and back port. It's early 10 stage 1 now > > (you can try my pending patch series from > https://github.com/iains/gcc-8-branch, I don't expect to make too much > change from that). > > the key patch for this is - > https://github.com/iains/gcc-8-branch/commit/ > 85d8544e8cfab2e89198e83373b169b29c429777 > > but it probably won't apply cleanly without the preceding ones.
[Bug bootstrap/87030] GCC fails to build with Xcode 10, attempting an impossible multilib build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87030 Iain Sandoe changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org Target Milestone|--- |8.4 --- Comment #17 from Iain Sandoe --- I have a patch series to fix this - but it's not really appropriate this late in stage 4. So plan is to fix in early 10 stage 1 and back port. (you can try my pending patch series from https://github.com/iains/gcc-8-branch, I don't expect to make too much change from that). the key patch for this is - https://github.com/iains/gcc-8-branch/commit/85d8544e8cfab2e89198e83373b169b29c429777 but it probably won't apply cleanly without the preceding ones.
[Bug bootstrap/87030] GCC fails to build with Xcode 10, attempting an impossible multilib build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87030 --- Comment #16 from Eric Gallager --- (In reply to Iain Sandoe from comment #15) > FWIW I had a quick look the other day if there was an easy fix to this PR, > and didn't find a '5 minute' one. > > (In reply to Eric Gallager from comment #14) > > (In reply to Iain Sandoe from comment #13) > > > (In reply to Jeremy Huddleston Sequoia from comment #12) > > > > (In reply to Francois-Xavier Coudert from comment #11) > > > > > (In reply to Jeremy Huddleston Sequoia from comment #10) > > > > Of course, one *can* pass --sysroot=`xcrun blah blah` on any command line > > > (for the built compiler) as a work-around. > > > > > > I was trying to work on a scheme where the possible SDK search paths were > > > provided by symlinks [in the user's home dir], with some configure-time > > > specified search order (including the option to search /). Initial > > > population of the symlinks might be time-significant - but subsequent > > > following should be less than a process switch. There was some email > > > exchange on this between me, Eric and Mike .. I will try to find it in my > > > archives. > > > > You found it yet? > > Yes... it's in my (unfortunately large) stack of things to be forward-ported. > > Please see also comments on PR79885 > > Also making a proper fix for PR84257 might involve reorganising things (in > particular shifting from using absolute library paths to @rpath ones, for > 10.5+ [not available on 10.4]). > > IMO, we really need to set out how we want Darwin toolchains to behave for > the end user, and then figure out how to make the build and test work to > support that. This is non-trivial in the presence of SIP, user-movable > packages, and the library naming scheme. Still working on this.. but > equally open to suggestions. > > It's certainly true that one use-case is "build a self-hosted GCC using > Xcode" but that's definitely not the only scenario, and we [some of us at > least] don't want to be locked into it. At least personally I'd like to get away from the "using Xcode" part some day... > > The other fact of life is that there are now such significant discrepancies > between darwin versions from 8 .. 18 that we might no longer be able to > avoid multi-libs to support the range properly.
[Bug bootstrap/87030] GCC fails to build with Xcode 10, attempting an impossible multilib build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87030 --- Comment #15 from Iain Sandoe --- FWIW I had a quick look the other day if there was an easy fix to this PR, and didn't find a '5 minute' one. (In reply to Eric Gallager from comment #14) > (In reply to Iain Sandoe from comment #13) > > (In reply to Jeremy Huddleston Sequoia from comment #12) > > > (In reply to Francois-Xavier Coudert from comment #11) > > > > (In reply to Jeremy Huddleston Sequoia from comment #10) > > Of course, one *can* pass --sysroot=`xcrun blah blah` on any command line > > (for the built compiler) as a work-around. > > > > I was trying to work on a scheme where the possible SDK search paths were > > provided by symlinks [in the user's home dir], with some configure-time > > specified search order (including the option to search /). Initial > > population of the symlinks might be time-significant - but subsequent > > following should be less than a process switch. There was some email > > exchange on this between me, Eric and Mike .. I will try to find it in my > > archives. > > You found it yet? Yes... it's in my (unfortunately large) stack of things to be forward-ported. Please see also comments on PR79885 Also making a proper fix for PR84257 might involve reorganising things (in particular shifting from using absolute library paths to @rpath ones, for 10.5+ [not available on 10.4]). IMO, we really need to set out how we want Darwin toolchains to behave for the end user, and then figure out how to make the build and test work to support that. This is non-trivial in the presence of SIP, user-movable packages, and the library naming scheme. Still working on this.. but equally open to suggestions. It's certainly true that one use-case is "build a self-hosted GCC using Xcode" but that's definitely not the only scenario, and we [some of us at least] don't want to be locked into it. The other fact of life is that there are now such significant discrepancies between darwin versions from 8 .. 18 that we might no longer be able to avoid multi-libs to support the range properly.
[Bug bootstrap/87030] GCC fails to build with Xcode 10, attempting an impossible multilib build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87030
--- Comment #14 from Eric Gallager ---
(In reply to Iain Sandoe from comment #13)
> (In reply to Jeremy Huddleston Sequoia from comment #12)
> > (In reply to Francois-Xavier Coudert from comment #11)
> > > (In reply to Jeremy Huddleston Sequoia from comment #10)
> > > > Given those, gcc only builds if we have the DevSDK ("headers at /"
> > > > package)
> > > > installed.
> > >
> > > I may be misunderstanding what you say: GCC builds and runs fine without
> > > the
> > > headers in /usr/include. At Homebrew, we are not recommending users to
> > > install the /usr/include headers package, and we build and run GCC fine.
> > > The
> > > configuration is the following
> > > (https://github.com/Homebrew/homebrew-core/blob/master/Formula/gcc.rb):
> > >
> > > --with-native-system-header-dir=/usr/include
> > > --with-sysroot=/path/to/sdk
> > >
> > > if the system headers are in /path/to/sdk/usr/include. Thus, on a Mojave
> > > installation with Xcode CLT installed, we set /path/to/sdk to
> > > /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
> >
> > Yeah, I documented the workaround of using --with-sysroot in the MacPorts
> > port when filing these bugs and passed on to Homebrew, but that ends up
> > causing gcc's search path to always look in that sysroot (ie, it becomes the
> > default sysroot). Thus, users will build executables that behave
> > differently based on where there SDK was located on their build system.
> > That is certainly not what is desired. If you have a build fleet that used
> > an SDK that was located at /Volumes/SDKs/AllMacSDKs/MacOSX10.14.sdk at build
> > time, but your users have
> > /Applications/MyXcodesPath/Xcode-10.app/.../MacOSX.sdk, then that mismatch
> > can cause problems.
> >
> > The point of --with-sysroot is to change the behavior of the built product
> > (the final gcc executable).
>
> Right - this is pretty much the comment I made in 87243; --with-sysroot=
> sets the default, which might not be the one implied by an xcode-select
> executed later.
>
> Of course, one *can* pass --sysroot=`xcrun blah blah` on any command line
> (for the built compiler) as a work-around.
>
> I was trying to work on a scheme where the possible SDK search paths were
> provided by symlinks [in the user's home dir], with some configure-time
> specified search order (including the option to search /). Initial
> population of the symlinks might be time-significant - but subsequent
> following should be less than a process switch. There was some email
> exchange on this between me, Eric and Mike .. I will try to find it in my
> archives.
You found it yet?
>
> IMO we really don't want to go down the road where we launch another
> executable for every sub-process invocation on the toolchain that needs to
> know the SDK path!
>
> > The point of --with-build-sysroot is to change
> > how we build gcc.
>
> Indeed --with-build-sysroot has some nasties - I did some work on it for
> darwin when trying to get to a situation where we can configure for
> "x86_64-apple-darwin" without that implying 10.0 ;)
>
> Need to fish that out too.
[Bug bootstrap/87030] GCC fails to build with Xcode 10, attempting an impossible multilib build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87030
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-09-21
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=87243
Ever confirmed|0 |1
--- Comment #13 from Iain Sandoe ---
(In reply to Jeremy Huddleston Sequoia from comment #12)
> (In reply to Francois-Xavier Coudert from comment #11)
> > (In reply to Jeremy Huddleston Sequoia from comment #10)
> > > Given those, gcc only builds if we have the DevSDK ("headers at /"
> > > package)
> > > installed.
> >
> > I may be misunderstanding what you say: GCC builds and runs fine without the
> > headers in /usr/include. At Homebrew, we are not recommending users to
> > install the /usr/include headers package, and we build and run GCC fine. The
> > configuration is the following
> > (https://github.com/Homebrew/homebrew-core/blob/master/Formula/gcc.rb):
> >
> > --with-native-system-header-dir=/usr/include
> > --with-sysroot=/path/to/sdk
> >
> > if the system headers are in /path/to/sdk/usr/include. Thus, on a Mojave
> > installation with Xcode CLT installed, we set /path/to/sdk to
> > /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
>
> Yeah, I documented the workaround of using --with-sysroot in the MacPorts
> port when filing these bugs and passed on to Homebrew, but that ends up
> causing gcc's search path to always look in that sysroot (ie, it becomes the
> default sysroot). Thus, users will build executables that behave
> differently based on where there SDK was located on their build system.
> That is certainly not what is desired. If you have a build fleet that used
> an SDK that was located at /Volumes/SDKs/AllMacSDKs/MacOSX10.14.sdk at build
> time, but your users have
> /Applications/MyXcodesPath/Xcode-10.app/.../MacOSX.sdk, then that mismatch
> can cause problems.
>
> The point of --with-sysroot is to change the behavior of the built product
> (the final gcc executable).
Right - this is pretty much the comment I made in 87243; --with-sysroot= sets
the default, which might not be the one implied by an xcode-select executed
later.
Of course, one *can* pass --sysroot=`xcrun blah blah` on any command line (for
the built compiler) as a work-around.
I was trying to work on a scheme where the possible SDK search paths were
provided by symlinks [in the user's home dir], with some configure-time
specified search order (including the option to search /). Initial population
of the symlinks might be time-significant - but subsequent following should be
less than a process switch. There was some email exchange on this between me,
Eric and Mike .. I will try to find it in my archives.
IMO we really don't want to go down the road where we launch another executable
for every sub-process invocation on the toolchain that needs to know the SDK
path!
> The point of --with-build-sysroot is to change
> how we build gcc.
Indeed --with-build-sysroot has some nasties - I did some work on it for darwin
when trying to get to a situation where we can configure for
"x86_64-apple-darwin" without that implying 10.0 ;)
Need to fish that out too.
[Bug bootstrap/87030] GCC fails to build with Xcode 10, attempting an impossible multilib build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87030
--- Comment #12 from Jeremy Huddleston Sequoia
---
(In reply to Francois-Xavier Coudert from comment #11)
> (In reply to Jeremy Huddleston Sequoia from comment #10)
> > Given those, gcc only builds if we have the DevSDK ("headers at /" package)
> > installed.
>
> I may be misunderstanding what you say: GCC builds and runs fine without the
> headers in /usr/include. At Homebrew, we are not recommending users to
> install the /usr/include headers package, and we build and run GCC fine. The
> configuration is the following
> (https://github.com/Homebrew/homebrew-core/blob/master/Formula/gcc.rb):
>
> --with-native-system-header-dir=/usr/include
> --with-sysroot=/path/to/sdk
>
> if the system headers are in /path/to/sdk/usr/include. Thus, on a Mojave
> installation with Xcode CLT installed, we set /path/to/sdk to
> /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
Yeah, I documented the workaround of using --with-sysroot in the MacPorts port
when filing these bugs and passed on to Homebrew, but that ends up causing
gcc's search path to always look in that sysroot (ie, it becomes the default
sysroot). Thus, users will build executables that behave differently based on
where there SDK was located on their build system. That is certainly not what
is desired. If you have a build fleet that used an SDK that was located at
/Volumes/SDKs/AllMacSDKs/MacOSX10.14.sdk at build time, but your users have
/Applications/MyXcodesPath/Xcode-10.app/.../MacOSX.sdk, then that mismatch can
cause problems.
The point of --with-sysroot is to change the behavior of the built product (the
final gcc executable). The point of --with-build-sysroot is to change how we
build gcc.
[Bug bootstrap/87030] GCC fails to build with Xcode 10, attempting an impossible multilib build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87030
--- Comment #11 from Francois-Xavier Coudert ---
(In reply to Jeremy Huddleston Sequoia from comment #10)
> Given those, gcc only builds if we have the DevSDK ("headers at /" package)
> installed.
I may be misunderstanding what you say: GCC builds and runs fine without the
headers in /usr/include. At Homebrew, we are not recommending users to install
the /usr/include headers package, and we build and run GCC fine. The
configuration is the following
(https://github.com/Homebrew/homebrew-core/blob/master/Formula/gcc.rb):
--with-native-system-header-dir=/usr/include
--with-sysroot=/path/to/sdk
if the system headers are in /path/to/sdk/usr/include. Thus, on a Mojave
installation with Xcode CLT installed, we set /path/to/sdk to
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
[Bug bootstrap/87030] GCC fails to build with Xcode 10, attempting an impossible multilib build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87030
--- Comment #10 from Jeremy Huddleston Sequoia
---
FWIW, I don't have much power other than nagging to move along the OSS drops.
Those are managed by a process, and prioritization is given to those making
explicit requests to the OSS mailing list. *PLEASE* email opensou...@apple.com
directly (and feel free to CC me).
I agree with pretty much all Iain has said here. There's nothing that should
be different about how gcc treats i386 on darwin vs how it treats i386 on
linux.
Note that for us, the far bigger concerns are the broken --with-build-sysroot
support:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79885
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80203
Given those, gcc only builds if we have the DevSDK ("headers at /" package)
installed. That package is being provided as a workaround for any projects
that fail to build without it (and note that GCC is the only project we are
aware of that falls into this category). In some future macOS version, it will
cease to be provided. I strongly encourage you to address those issues as soon
as possible to ensure that GCC continues to build with future versions.
[Bug bootstrap/87030] GCC fails to build with Xcode 10, attempting an impossible multilib build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87030 --- Comment #9 from joseph at codesourcery dot com --- On Sat, 8 Sep 2018, iains at gcc dot gnu.org wrote: > 2. Actually, you get the same failure on GNU-Linux if you try to configure > defaults on (for example) an x86_64 system without 32bit libs installed (one > has to add --disable-multilib there, or install 32b libs), so automation is > not > the default on Linux. The toplevel configure.ac code # Special user-friendly check for native x86_64-linux build, if # multilib is not explicitly enabled. case "$target:$have_compiler:$host:$target:$enable_multilib" in x86_64-*linux*:yes:$build:$build:) # Make sure we have a development environment that handles 32-bit [...] is meant to give a more helpful error in that case: AC_MSG_ERROR([I suspect your system does not have 32-bit development libraries (libc and headers). If you have them, rerun configure with --enable-multilib. If you do not have them, and want to build a 64-bit-only compiler, rerun configure with --disable-multilib.])
[Bug bootstrap/87030] GCC fails to build with Xcode 10, attempting an impossible multilib build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87030 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org, ||jeremyhu at macports dot org --- Comment #8 from Eric Gallager --- (In reply to Jack Howarth from comment #7) > (In reply to Iain Sandoe from comment #6) > > We are not dependent on the Xcode supplied tools for some time now, since > > upstream dsymutil is functional. So, if that were to happen - we would > > simply (as the Linux folks do) build a complete toolchain rather than just > > the compiler (i have a 'cctools' look-alike driver for the LLVM backend - > > and an actual cctools assembler with the known bugs fixed). > > > > While using the assembler from llvm should be straight forward enough, > assuming Apple didn't push its obsoleting of i386 changes upstream, the > linker would be a tricker issue since the llvm lld code hasn't been kept up > on the Darwin side for quite some time. > > > To assist this, it would be helpful if fink, macports etc. could file radars > > noting that the open source releases are very out of date for these > > components (currently 8.2.1 compared with the released Xcode of 10.x) > > I pinged Jeremy to see if he can nudge that along. cc-ing him on this bug, too
[Bug bootstrap/87030] GCC fails to build with Xcode 10, attempting an impossible multilib build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87030 --- Comment #7 from Jack Howarth --- (In reply to Iain Sandoe from comment #6) > We are not dependent on the Xcode supplied tools for some time now, since > upstream dsymutil is functional. So, if that were to happen - we would > simply (as the Linux folks do) build a complete toolchain rather than just > the compiler (i have a 'cctools' look-alike driver for the LLVM backend - > and an actual cctools assembler with the known bugs fixed). > While using the assembler from llvm should be straight forward enough, assuming Apple didn't push its obsoleting of i386 changes upstream, the linker would be a tricker issue since the llvm lld code hasn't been kept up on the Darwin side for quite some time. > To assist this, it would be helpful if fink, macports etc. could file radars > noting that the open source releases are very out of date for these > components (currently 8.2.1 compared with the released Xcode of 10.x) I pinged Jeremy to see if he can nudge that along.
[Bug bootstrap/87030] GCC fails to build with Xcode 10, attempting an impossible multilib build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87030 --- Comment #6 from Iain Sandoe --- (In reply to Jack Howarth from comment #5) > (In reply to Iain Sandoe from comment #3) > > > > > 3. I don't see why GCC should be subject to the vendor's support policy. As > > far as I am concerned, with the right SDK / sysroot available, there's no > > reason why a compiler *hosted* on x86-64-Darwin18 shouldn't be able to build > > code for i686-darwin10 *target*. > > That makes the assumption that the cctools in some future macOS release > won't obsolete out the code for support i386 assembly and linkage. I > wouldn't be surprised if that actually happened should Apple start making > arm64-apple-darwin a thing. We are not dependent on the Xcode supplied tools for some time now, since upstream dsymutil is functional. So, if that were to happen - we would simply (as the Linux folks do) build a complete toolchain rather than just the compiler (i have a 'cctools' look-alike driver for the LLVM backend - and an actual cctools assembler with the known bugs fixed). To assist this, it would be helpful if fink, macports etc. could file radars noting that the open source releases are very out of date for these components (currently 8.2.1 compared with the released Xcode of 10.x)
[Bug bootstrap/87030] GCC fails to build with Xcode 10, attempting an impossible multilib build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87030 --- Comment #5 from Jack Howarth --- (In reply to Iain Sandoe from comment #3) > > 3. I don't see why GCC should be subject to the vendor's support policy. As > far as I am concerned, with the right SDK / sysroot available, there's no > reason why a compiler *hosted* on x86-64-Darwin18 shouldn't be able to build > code for i686-darwin10 *target*. That makes the assumption that the cctools in some future macOS release won't obsolete out the code for support i386 assembly and linkage. I wouldn't be surprised if that actually happened should Apple start making arm64-apple-darwin a thing.
[Bug bootstrap/87030] GCC fails to build with Xcode 10, attempting an impossible multilib build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87030 --- Comment #4 from Jack Howarth --- A couple notes here. 1) As I mentioned in the duplicate PR 87257, Apple achieved the obsoleting of the i386 support in Xcode 10 through the libSystem.tbd in the 10.14 SDK's buried /usr/lib/libSystem.tbd which only exposes the x86_64 symbols from the root level /usr/lib/libSystem.dylib. So one could hack continued support for i386 in for awhile more if gcc replaced its -lSystem linkage with an explicit /usr/lib/libSystem.dylib linkage. 2) Since the default behavior for the command line tools from Xcode 10 are to not install the SDK in the root directory, the gcc compiler needs to be bootstrapped with--with-sysroot=$SDK_PATH to build under Xcode 10 on 10.14. This issue doesn't exist on 10.13 which still installs the system headers in the root directory.
[Bug bootstrap/87030] GCC fails to build with Xcode 10, attempting an impossible multilib build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87030 --- Comment #3 from Iain Sandoe --- Just a few notes: 1. I'm not objecting to some kind of automation to switch off the 32b multiline where the *target* system is >= 10.14/Darwin18 (someone needs to write it, that's all). 2. Actually, you get the same failure on GNU-Linux if you try to configure defaults on (for example) an x86_64 system without 32bit libs installed (one has to add --disable-multilib there, or install 32b libs), so automation is not the default on Linux. 3. I don't see why GCC should be subject to the vendor's support policy. As far as I am concerned, with the right SDK / sysroot available, there's no reason why a compiler *hosted* on x86-64-Darwin18 shouldn't be able to build code for i686-darwin10 *target*.
[Bug bootstrap/87030] GCC fails to build with Xcode 10, attempting an impossible multilib build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87030 Iain Sandoe changed: What|Removed |Added CC||howarth.at.gcc at gmail dot com --- Comment #2 from Iain Sandoe --- *** Bug 87257 has been marked as a duplicate of this bug. ***
[Bug bootstrap/87030] GCC fails to build with Xcode 10, attempting an impossible multilib build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87030 Iain Sandoe changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #1 from Iain Sandoe --- (In reply to Francois-Xavier Coudert from comment #0) > Building with Xcode 10 (beta) on macOS 10.13 or 10.14 (beta), leads to a > build failure because by default, configure sets GCC up for a multilib > build. However, starting with Xcode 10, Apple has removed support for > 32-bit: thus, the builds fails when trying to link libgcc, because it does > not find the 32-bit system libc. > > Passing --disable-multilib fixes bootstrap. However, the default configure > should detect that 32-bit is not supported and automatically build without > 32-bit multilib. Agreed; I was kinda expecting this - do you have a patch? ( or I can add it to the TODO ;) )
