Created attachment 218655 [details] config.log I was trying to install bhyve-firmware from ports. gcc48 is a dependency, but it failed during the configure phase. I checked the config.log, and it appears that the primary problem is in regard to the ISL library. I'm running 13.0-CURRENT #4 88ab3e83466-c272139(master). gmake[5]: Leaving directory '/usr/ports/lang/gcc48/work/.build/gcc' mkdir x86_64-portbld-freebsd13.0/libgcc Checking multilib configuration for libgcc... Configuring stage 1 in x86_64-portbld-freebsd13.0/libgcc configure: creating cache ./config.cache checking build system type... x86_64-portbld-freebsd13.0 checking host system type... x86_64-portbld-freebsd13.0 checking for --enable-version-specific-runtime-libs... no checking for a BSD-compatible install... /usr/bin/install -c checking for gawk... /usr/bin/awk checking for x86_64-portbld-freebsd13.0-ar... /usr/local/x86_64-portbld-freebsd13.0/bin/ar checking for x86_64-portbld-freebsd13.0-lipo... lipo checking for x86_64-portbld-freebsd13.0-nm... /usr/ports/lang/gcc48/work/.build/./gcc/nm checking for x86_64-portbld-freebsd13.0-ranlib... /usr/local/x86_64-portbld-freebsd13.0/bin/ranlib checking for x86_64-portbld-freebsd13.0-strip... /usr/local/x86_64-portbld-freebsd13.0/bin/strip checking whether ln -s works... yes checking for x86_64-portbld-freebsd13.0-gcc... /usr/ports/lang/gcc48/work/.build/./gcc/xgcc -B/usr/ports/lang/gcc48/work/.build/./gcc/ -B/usr/local/x86_64-portbld-freebsd13.0/bin/ -B/usr/local/x86_64-portbld-freebsd13.0/lib/ -isystem /usr/local/x86_64-portbld-freebsd13.0/include -isystem /usr/local/x86_64-portbld-freebsd13.0/sys-include checking for suffix of object files... configure: error: in `/usr/ports/lang/gcc48/work/.build/x86_64-portbld-freebsd13.0/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. gmake[4]: *** [Makefile:13844: configure-stage1-target-libgcc] Error 1 gmake[4]: Leaving directory '/usr/ports/lang/gcc48/work/.build' gmake[3]: *** [Makefile:18677: stage1-bubble] Error 2 gmake[3]: Leaving directory '/usr/ports/lang/gcc48/work/.build' gmake[2]: *** [Makefile:18993: bootstrap-lean] Error 2 gmake[2]: Leaving directory '/usr/ports/lang/gcc48/work/.build' ===> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to the maintainer. *** Error code 1
(In reply to Patrick McMunn from comment #0) > I was trying to install bhyve-firmware from ports. gcc48 is a dependency, > but it failed during the configure phase. Yes, it is unfortunate that bhyve-firmware (via uefi-edk2-bhyve) still depends on GCC 4.8 which went end of life upstream more than five years ago. > I checked the config.log, and it appears that the primary problem is > in regard to the ISL library. I'm running 13.0-CURRENT #4 88ab3e83466- > c272139(master). That's a red herring. configure checks for that, but it's only used by an experimental feature called Graphite that we do not have enabled. I believe the actual hint is configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. which in 9 out of 10 cases is an indication that some special, non-default system configuration or explicit flag set by the user breaks things. Does that trigger nay ideas?
Last night I had a chance to look more deeply into this. It turned out that the reason it failed to build is because I had CPUTYPE?=westmere in my /etc/make.conf. This is normally a benign setting, so it wasn't something I suspected immediately, and I have almost no settings deviating from defaults other than some port options. But I guess that since gcc48 is used to build itself once it's bootstrapped, it failed because this old version doesn't support that flag. So it makes sense in retrospect. In any case, I think this can be closed. However, a Google search shows that this isn't the first time this sort of bug has been reported for lang/gcc48 (see, for example bug 218819 from 2017 and bug 244654 from March of this year). So I would concur with the suggestion from 2017 that this port ought to emit an informational message in the event that it fails to build which notifies the user to omit custom CPUTYPE flags or other unusual settings before filing a bug. Otherwise there is bound to be more unnecessary bug reports.
Created attachment 218751 [details] Patch to filter out -march=westmere from CFLAGS/CXXFLAGS You are right, it would be nice to diagnose such cases more gently. Just the number of options is quite large and this is best done by the compiler (or its build framework) itself, which may happen with a current version if someone volunteers, alas GCC 4.8 has been end of life for half a decade already. Still, let me see ... does the attached patch work around the issue for you?
A commit references this bug: Author: gerald Date: Sun Oct 18 09:07:44 UTC 2020 New revision: 552624 URL: https://svnweb.freebsd.org/changeset/ports/552624 Log: Remove -march=westmere from CFLAGS and CXXFLAGS if present since this old version of GCC (end of life for more than five years) does not yet support the Intel Westmere architecture. [1] This avoids breaking users who set a global CPUTYPE to westmere. While here, backport r469788 from lang/gcc6: [2] Filter the -mretpoline command-line option, which is understood by recent versions of clang (and used in the context of the Spectre security issues), but not GCC (which uses different options for the same) from CFLAGS and CXXFLAGS. This avoids the build of this port via bootstrap, which is the default and leverages both the system compiler (clang in most cases) plus a just built version GCC, to fail due to the latter not knowing -mretpoline. PR: 250263 [1], 228205 [2] Reported by: Patrick McMunn <doctorwhoguy@gmail.com> [1] Submitted by: rozhuk.im@gmail.com [2] Changes: head/lang/gcc48/Makefile
(In reply to Gerald Pfeifer from comment #3) > Still, let me see ... does the attached patch work around the issue for you? I went ahead and committed this. With a bit of luck lang/gcc48 should now build for you, even with that CPUTYPE setting present. Based on my own tests I am closing the report. If you still can confirm, that would be nice - thank you!
I missed the notification that you responded on the 15th. But portsnap pulled in the updated port this morning, and I tested it. It compiled and installed without any trouble. Thank you!
Excellent. Thank you for the update, Patrick!