Libunwind causes gcc13, gcc14 build failures

[barracuda156]

As of now, building from source of new gccs still fail for me:

:info:build checking for unistd.h... 1 warning generated.
:info:build if [ x"" != x ]; then \
:info:build 	  /usr/bin/clang -arch arm64 -c -DHAVE_CONFIG_H -pipe -Os -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk -I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk -I. -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc14/libgcc14/work/gcc-14.1.0/libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -Wshadow=local -pedantic  -D_GNU_SOURCE  -fno-common  /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc14/libgcc14/work/gcc-14.1.0/libiberty/fibheap.c -o noasan/fibheap.o; \
:info:build 	else true; fi
:info:build /usr/bin/clang -arch arm64 -c -DHAVE_CONFIG_H -pipe -Os -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk -I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk -I. -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc14/libgcc14/work/gcc-14.1.0/libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -Wshadow=local -pedantic  -D_GNU_SOURCE  /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc14/libgcc14/work/gcc-14.1.0/libiberty/fibheap.c -o fibheap.o
:info:build yes
:info:build checking minix/config.h usability... warning: unknown warning option '-Wshadow=local' [-Wunknown-warning-option]
:info:build yes
:info:build checking for CFLocaleCopyPreferredLanguages... 1 warning generated.
:info:build if [ x"-fno-common" != x ]; then \
:info:build 	  /usr/bin/clang -arch arm64 -c -DHAVE_CONFIG_H -pipe -Os -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk -I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX14.sdk -I. -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc14/libgcc14/work/gcc-14.1.0/libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -Wshadow=local -pedantic  -D_GNU_SOURCE  -fno-common /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc14/libgcc14/work/gcc-14.1.0/libiberty/filedescriptor.c -o pic/filedescriptor.o; \
:info:build 	else true; fi
:info:build no
:info:build checking minix/config.h presence... warning: unknown warning option '-Wshadow=local' [-Wunknown-warning-option]
:info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc14/libgcc14/work/gcc-14.1.0/libiberty/filedescriptor.c:45:10: error: call to undeclared function 'dup2'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
:info:build   return dup2 (fd, fd) < 0;
:info:build          ^
:info:build 1 warning and 1 error generated.
:info:build make[3]: *** [filedescriptor.o] Error 1
:info:build make[3]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc14/libgcc14/work/build/build-arm64-apple-darwin23/libiberty'
:info:build make[2]: *** [all-build-libiberty] Error 2
:info:build make[2]: *** Waiting for unfinished jobs....

I did try deactivating everything, removing all custom port files and installing from scratch.

[cjones051073 (Chris Jones)]

Works fine on buildbots.

​https://ports.macports.org/port/gcc14/builds/

​https://ports.macports.org/port/gcc13/builds/

Please compare the logs there to yours and report if you can spot any relevant differences.

[cjones051073 (Chris Jones)]

Also please post full logs here. The snippet above is not enough to deduce much.

[cjones051073 (Chris Jones)]

what is your reason for building from source, instead of just using the binary tarballs now available ?

[jmroot (Joshua Root)]

It does seem to be missing a unistd.h include for the fallback case that uses dup2, but it should not be using that fallback because F_GETFD should definitely be defined in fcntl.h.

[barracuda156]

Replying to cjones051073:

Also please post full logs here. The snippet above is not enough to deduce much.

Done now, sorry for a delay, got distracted.

After several attempts I got the build running further from this point without anything obvious changed in the environment, so I have no idea what and why fails and what made the difference.

For now, please keep the issue opened, I wanna verify it works reproducibly.

[barracuda156]

Replying to cjones051073:

what is your reason for building from source, instead of just using the binary tarballs now available ?

We had failures before, discussed those with Iain, so I naturally wanted to check that we do not get them anymore.

[cjones051073 (Chris Jones)]

just for completeness please confirm what versions of cctools and ld64 you are using ? You should be using the default 'Xcode' variant of each

Larissa ~/Projects/MacPorts/ports > port info cctools ld64
cctools @949.0.1_3 (devel)
Variants:             llvm10, llvm11, llvm12, llvm13, llvm14, llvm15, llvm16, llvmdev, [+]xcode, xtools

Description:          A set of essential tools to support development on Mac OS X and Darwin. Conceptually similar to binutils
                      on other platforms.
Homepage:             https://opensource.apple.com/source/cctools/

Platforms:            darwin any
License:              (APSL-2 or GPL-2+)
Maintainers:          Email: jeremyhu@macports.org, GitHub: jeremyhu
                      Policy: openmaintainer
--
ld64 @3_6 (devel)
Sub-ports:            ld64-97, ld64-127, ld64-236, ld64-274, ld64-latest, ld64-xcode, ld64-xtools
Variants:             ld64_127, ld64_236, ld64_274, ld64_97, [+]ld64_xcode, ld64_xtools, universal

Description:          ld64 combines several object files and libraries, resolves references, and produces an output file.
Homepage:             http://opensource.apple.com/source/ld64/

Runtime Dependencies: ld64-xcode
Platforms:            darwin
License:              APSL-2
Maintainers:          Email: jeremyhu@macports.org, GitHub: jeremyhu

[cjones051073 (Chris Jones)]

Replying to barracuda156:

Replying to cjones051073:

what is your reason for building from source, instead of just using the binary tarballs now available ?

We had failures before, discussed those with Iain, so I naturally wanted to check that we do not get them anymore.

OK, I wanted to check it was not because you had some 'unusual' configuration.

Those errors are now I am sure fixed, as you can see from the buildbot builds, so whilst you are welcome to cross check there is no need really.

[cjones051073 (Chris Jones)]

Also, just for the benefit of others the discussion referred to with Iain is here

​https://github.com/iains/gcc-13-branch/issues/20

[barracuda156]

Replying to cjones051073:

Replying to barracuda156:

Replying to cjones051073:

what is your reason for building from source, instead of just using the binary tarballs now available ?

We had failures before, discussed those with Iain, so I naturally wanted to check that we do not get them anymore.

OK, I wanted to check it was not because you had some 'unusual' configuration.

Whenever I build in a non-standard environment and it is not obvious, I normally mention it. On Sonoma my main MacPorts installation is standard (and anything above 10.6 is standard, though I rarely use those systems). I did have some irrelevant WIP ports (gnome, ruby), but I moved out everything from my overlay repo when I was trying to build after the initial failure.

16. S. The only thing I noticed later which was not default (but still unmodified port from the master) was isl-devel, but when it started working, I still had isl-devel, and right now running the build with it, so it is not related to the failure.

[barracuda156]

Replying to cjones051073:

just for completeness please confirm what versions of cctools and ld64 you are using ? You should be using the default 'Xcode' variant of each

svacchanda@43-200 ~ % port info cctools ld64
cctools @949.0.1_3 (devel)
Variants:             llvm10, llvm11, llvm12, llvm13, llvm14, llvm15, llvm16,
                      llvmdev, [+]xcode, xtools

Description:          A set of essential tools to support development on Mac OS
                      X and Darwin. Conceptually similar to binutils on other
                      platforms.
Homepage:             https://opensource.apple.com/source/cctools/

Platforms:            darwin any
License:              (APSL-2 or GPL-2+)
Maintainers:          Email: jeremyhu@macports.org, GitHub: jeremyhu
                      Policy: openmaintainer
--
ld64 @3_6 (devel)
Sub-ports:            ld64-97, ld64-127, ld64-236, ld64-274, ld64-latest,
                      ld64-xcode, ld64-xtools
Variants:             ld64_127, ld64_236, ld64_274, ld64_97, [+]ld64_xcode,
                      ld64_xtools

Description:          ld64 combines several object files and libraries, resolves
                      references, and produces an ouput file.
Homepage:             http://opensource.apple.com/source/ld64/

Runtime Dependencies: ld64-xcode
Platforms:            darwin
License:              APSL-2
Maintainers:          Email: jeremyhu@macports.org, GitHub: jeremyhu

[ryandesign (Ryan Carsten Schmidt)]

In your logs I see:

:info:configure ld: warning: reexported library with install name '/opt/local/lib/libunwind.1.dylib' found at '/opt/local/lib/libunwind.1.dylib' couldn't be matched with any parent library and will be linked directly

That's not in the buildbot logs because these ports don't depend on libunwind. We already know that having libunwind installed and active causes ports to fail to build (#66250). Try deactivating it, cleaning, and building again.

[barracuda156]

Replying to ryandesign:

In your logs I see:

:info:configure ld: warning: reexported library with install name '/opt/local/lib/libunwind.1.dylib' found at '/opt/local/lib/libunwind.1.dylib' couldn't be matched with any parent library and will be linked directly

I think I deactivated everything when rebuilding last time, but maybe something did not work.

Anyway, I uninstalled everything, started from scratch and was able to build both libgcc14 and gcc14 from source now (with isl-devel):

svacchanda@43-200 ~ % port -v installed libgcc14 gcc14
The following ports are currently installed:
  gcc14 @14.1.0_0+stdlib_flag (active) requested_variants='' platform='darwin 23' archs='arm64' date='2024-07-05T02:38:12+0800'
  libgcc14 @14.1.0_0+stdlib_flag (active) requested_variants='' platform='darwin 23' archs='arm64' date='2024-07-05T00:47:40+0800'

[cjones051073 (Chris Jones)]

Gcc already declares a build conflict against the libunwind headers, but perhaps this is no longer enough

​https://github.com/macports/macports-ports/blob/ee065f7787c786aa421c184690d6e365b6bec58b/lang/gcc14/Portfile#L332

?

[ryandesign (Ryan Carsten Schmidt)]

Per comment:ticket:66250:5:

It seems to me Xcode 15 brought changes that are causing this. With the libunwind port installed, building against libc++ the linker hooks up any binary to MacPorts' dylib making opportunistic linking for basically all C++ based ports.

So you would declare the build conflict against both libunwind and libunwind-headers. But since the problem affects all C++-using ports, it is probably silly to add that to all C++-using ports. Instead, the libunwind port should be fixed per comment:ticket:66250:1.