Bug 250263 - lang/gcc48 fails to configure with "cannot compute suffix of object files: cannot compile"
Summary: lang/gcc48 fails to configure with "cannot compute suffix of object files: ca...
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Gerald Pfeifer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-10-11 01:07 UTC by Patrick McMunn
Modified: 2020-10-19 07:18 UTC (History)
0 users

See Also:


Attachments
config.log (101.09 KB, text/plain)
2020-10-11 01:07 UTC, Patrick McMunn
no flags Details
Patch to filter out -march=westmere from CFLAGS/CXXFLAGS (377 bytes, patch)
2020-10-15 07:58 UTC, Gerald Pfeifer
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Patrick McMunn 2020-10-11 01:07:30 UTC
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
Comment 1 Gerald Pfeifer freebsd_committer 2020-10-11 11:42:05 UTC
(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?
Comment 2 Patrick McMunn 2020-10-15 02:46:47 UTC
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.
Comment 3 Gerald Pfeifer freebsd_committer 2020-10-15 07:58:53 UTC
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?
Comment 4 commit-hook freebsd_committer 2020-10-18 09:08:37 UTC
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
Comment 5 Gerald Pfeifer freebsd_committer 2020-10-18 09:20:36 UTC
(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!
Comment 6 Patrick McMunn 2020-10-18 17:45:12 UTC
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!
Comment 7 Gerald Pfeifer freebsd_committer 2020-10-19 07:18:52 UTC
Excellent. Thank you for the update, Patrick!