On Mon, Jan 7, 2019 at 1:37 PM NightStrike <nightstrike@xxxxxxxxx> wrote: > > I have been having a rough time lately building gcc with fortran > support. I keep running into this __cpu_model bug: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80600 > > 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 > 2.20.51.0.2-5.48.el6. I build the compiler with the following > configuration: > > Configured with: ../configure --prefix=/ --disable-nls > --disable-multilib --enable-languages=all,go,ada,obj-c++ > --enable-libstdcxx-time=rt --enable-plugins --with-gnu-as > --with-gnu-ld > > 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 > /tmp/gcc9/bin/../lib/gcc/x86_64-pc-linux-gnu/9.0.0/libgcc.a(cpuinfo.o) > 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 > loss here. > > Am I doing something wrong that's stupidly obvious? How are people > currently building gfortran successfully? > > Thanks for your help. Ping?
