search

iains / gcc-14-branch

GCC 14 for Darwin with experimental Arm64 support. Current release 14.2-darwin-r0 [August 2024]
GNU General Public License v2.0
4 stars 2 forks source link

When building (on Macports at least), does not respect SDKROOT #6

Closed lukaso closed 1 month ago

lukaso commented 1 month ago

On 14.5 when building gcc14, the SDKROOT variable is not used to fixup includes. This is the Macports issue: https://trac.macports.org/ticket/70328#comment:8

This has only turned up recently when libgcc was switched from gcc 13 to gcc 14 (I believe), but it may be generic to both gcc 13 and gcc 14.

The build error:

:info:build /Users/circleci/macports-gimp3-x86_64/var/macports/build/_Users_circleci_macports-gimp3-x86_64_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc14/libgcc14/work/build/gcc/include-fixed/AvailabilityInternal.h:185:10: fatal error: AvailabilityInternalLegacy.h: No such file or directory
:info:build   185 | #include <AvailabilityInternalLegacy.h>
:info:build       |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Setup with:

  echo 'macosx_deployment_target 11.0' | tee -a ${PREFIX}/etc/macports/macports.conf
  echo 'macosx_sdk_version 11.3' | tee -a ${PREFIX}/etc/macports/macports.conf

And

export SDKROOT=/Library/Developer/CommandLineTools/SDKs/MacOSX11.3.sdk

When looking in AvailabilityInternal.h it looks like it's ignoring the SDKROOT setting.

This is at the top:

/*  DO NOT EDIT THIS FILE.

    It has been auto-edited by fixincludes from:

    "/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/AvailabilityInternal.h"

    This had to be done to correct non-standard usages in the
    original, manufacturer supplied header file.  */

libgcc14-main.log AvailabilityInternal.h.txt

iains commented 1 month ago

SDKROOT will be respected by either GCC or clang compilers when building; however the GCC build system is generic - it has no idea that SDKROOT exists (or, indeed, MACOSX_DEPLOYMENT_TARGET). The configure needs to be passed --with-sysroot=/path/to/buildtime/SDK

NOTE that this does not cause a problem to the built compiler - which will still override the configure-time setting with an SDKROOT or --sysroot= passed at runtime.

If it's important to be able to use SDKROOT at configure time - please file an enhancement bug on the GCC bugzilla (https://gcc.gnu.org/bugzilla) and cc me - this is not specific to the branches here.

cjones051073 commented 1 month ago

--with-sysroot should be correctly set in the build according to the macports configuration parameter, due to

https://github.com/macports/macports-ports/blob/169504d70ab969c160518b462421ee5ca4c99642/lang/gcc14/Portfile#L221

However, @lukaso if you check the configure step for your build you can see

debug:configure system:  cd "/Users/circleci/macports-gimp3-x86_64/var/macports/build/_Users_circleci_macports-gimp3-x86_64_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc14/libgcc14/work/build" && /Users/circleci/macports-gimp3-x86_64/var/macports/build/_Users_circleci_macports-gimp3-x86_64_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc14/libgcc14/work/gcc-14.1.0/configure --prefix=/Users/circleci/macports-gimp3-x86_64 --build=x86_64-apple-darwin23 --enable-languages=c,c++,objc,obj-c++,lto,fortran --libdir=/Users/circleci/macports-gimp3-x86_64/lib/libgcc --infodir=/Users/circleci/macports-gimp3-x86_64/share/info --mandir=/Users/circleci/macports-gimp3-x86_64/share/man --datarootdir=/Users/circleci/macports-gimp3-x86_64/share/gcc-14 --with-local-prefix=/Users/circleci/macports-gimp3-x86_64 --with-system-zlib --disable-nls --program-suffix=-mp-14 --with-gxx-include-dir=/Users/circleci/macports-gimp3-x86_64/include/gcc/c++/ --with-gmp=/Users/circleci/macports-gimp3-x86_64 --with-mpfr=/Users/circleci/macports-gimp3-x86_64 --with-mpc=/Users/circleci/macports-gimp3-x86_64 --with-isl=/Users/circleci/macports-gimp3-x86_64 --with-zstd=/Users/circleci/macports-gimp3-x86_64 --enable-checking=release --disable-multilib --enable-lto --enable-libstdcxx-time --with-build-config=bootstrap-debug --with-as=/Users/circleci/macports-gimp3-x86_64/bin/as --with-ld=/Users/circleci/macports-gimp3-x86_64/bin/ld-classic --with-ar=/Users/circleci/macports-gimp3-x86_64/bin/ar --with-bugurl=https://trac.macports.org/newticket --enable-host-shared --with-darwin-extra-rpath=/Users/circleci/macports-gimp3-x86_64/lib/libgcc --with-libiconv-prefix=/Users/circleci/macports-gimp3-x86_64 --disable-tls --with-gxx-libcxx-include-dir="/Users/circleci/macports-gimp3-x86_64/libexec/gcc14/libc++/include/c++/v1" --with-pkgversion="MacPorts gcc14 14.1.0_0+stdlib_flag" --with-sysroot="/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk"

so for whatever reason this is not being propagated here and the build is using --with-sysroot="/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk

So @lukaso this is not an upstream issue. You ned to investigate why in your builds the SDK you wish to use is not making its way to this point and address that.

cjones051073 commented 1 month ago

OK, I see what is happening. See the comment at this line

https://github.com/macports/macports-ports/blob/169504d70ab969c160518b462421ee5ca4c99642/lang/gcc14/Portfile#L86

and the subsequent regex.

So this is intentional.

@iains Please feel free to close this as this is an internal MacPorts issue.

iains commented 1 month ago

closed - as macports internal - but you are welcome to file an upstream (i.e. GCC bugzilla) enhancement request for GCC configure to recognise SDKROOT if that seems useful.

FWIW: Personally, I prefer not to have important configuration information hidden in environment variables; those do not show in the 'config.status' in the build directory, nor in the output of gcc -v for the built compiler ..

Having said that, there are some (unusual) build cases for which one does need to use MACOSX_DEPLOYMENT_TARGET.

cooljeanius commented 3 weeks ago

closed - as macports internal - but you are welcome to file an upstream (i.e. GCC bugzilla) enhancement request for GCC configure to recognise SDKROOT if that seems useful.

FWIW: Personally, I prefer not to have important configuration information hidden in environment variables; those do not show in the 'config.status' in the build directory, nor in the output of gcc -v for the built compiler ..

Having said that, there are some (unusual) build cases for which one does need to use MACOSX_DEPLOYMENT_TARGET.

well, if you use the AC_ARG_VAR autoconf macro for it, that helps a bit...