This is the mail archive of the
mailing list for the GCC project.
Building gcc with broken gfortran
- From: NightStrike <nightstrike at gmail dot com>
- To: gcc-help <gcc-help at gcc dot gnu dot org>, "fortran at gcc dot gnu dot org" <fortran at gcc dot gnu dot org>
- Date: Mon, 7 Jan 2019 13:37:20 -0500
- Subject: Building gcc with broken gfortran
I have been having a rough time lately building gcc with fortran
support. I keep running into this __cpu_model bug:
This happens with 7.4, 8.2, and trunk as of this morning. All builds
are on RHEL6 using the system gcc 4.4.7 and system linker
126.96.36.199.2-5.48.el6. I build the compiler with the following
Configured with: ../configure --prefix=/ --disable-nls
--enable-libstdcxx-time=rt --enable-plugins --with-gnu-as
I use prefix=/ so I can relocate easily with DESTDIR. I use
enable-libstdcxx-time to get a fast clock_gettime on RHEL6. The
problem occurs with or without the "with-gnu-*" options.
Compiling a basic fortran hello world gives me:
/usr/bin/ld: a.out: hidden symbol `__cpu_model' in
is referenced by DSO
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error: ld returned 1 exit status
Just as mentioned in that PR. I have tried adding linker options like
-static-libgcc, -lgcc_s -l gcc, etc. and nothing seems to work. I
confirmed with readelf that the __cpu_model symbol in libgcc.a is
global hidden, but I can't figure out how to change it with objcopy.
But this is a pretty standard build of GCC on a stock RHEL6 system; it
should be working out of the box, or else many people would be
complaining I'd think.
I did find a few references online where other distro maintainers
applied local patches to add t-slibgcc-libgcc in various places, but
then others claim that that's a bad or dangerous solution. I'm at a
Am I doing something wrong that's stupidly obvious? How are people
currently building gfortran successfully?
Thanks for your help.