Dear Dr. Johansen,
Have you tried building the newly released GCC 9.1.0? After the
successful build, when I do "make check", I get:
make[1]: Entering directory '/lustre/work/oppe/gcc_workdir'
make[2]: Entering directory '/lustre/work/oppe/gcc_workdir/fixincludes'
autogen -T /lustre/work/oppe/gcc-9.1.0/fixincludes/check.tpl
/lustre/work/oppe/gcc-9.1.0/fixincludes/inc
lhack.def
/bin/bash ./check.sh /lustre/work/oppe/gcc-9.1.0/fixincludes/tests/base
Fixed: testing.h
Fixed: testing.h
Fixed: AvailabilityInternal.h
Fixed: AvailabilityMacros.h
Fixed: X11/ShellP.h
Fixed: X11/Xmu.h
Fixed: Xm/BaseClassI.h
Fixed: Xm/Traversal.h
Fixed: alloca.h
Fixed: ansi/math.h
Fixed: ansi/stdlib.h
Fixed: arch/i960/archI960.h
Fixed: architecture/ppc/math.h
Fixed: assert.h
Fixed: bits/fenv.h
Fixed: bits/huge_val.h
Fixed: bits/string2.h
Fixed: bsd/libc.h
Fixed: c_asm.h
Fixed: com_err.h
Fixed: complex.h
Fixed: ctrl-quotes-def-1.h
Fixed: ctype.h
Fixed: curses.h
Fixed: errno.h
Fixed: fcntl.h
Fixed: features.h
Fixed: fixinc-test-limits.h
Fixed: hsfs/hsfs_spec.h
Fixed: i386/setjmp.h
Fixed: ia64/sys/getppdp.h
Fixed: inttypes.h
Fixed: io-quotes-def-1.h
Fixed: ioLib.h
Fixed: iso/math_c99.h
Fixed: iso/math_iso.h
Fixed: iso/stdio_iso.h
Fixed: iso/stdlib_c99.h
Fixed: iso/stdlib_iso.h
Fixed: linux/vt.h
Fixed: locale.h
Fixed: mach-o/dyld.h
Fixed: mach-o/swap.h
Fixed: malloc.h
Fixed: math.h
Fixed: net/if.h
Fixed: net/if_arp.h
Fixed: netdnet/dnetdb.h
Fixed: netinet/in.h
Fixed: netinet/ip.h
Fixed: obstack.h
Fixed: os/trace.h
Fixed: pixrect/memvar.h
Fixed: pthread.h
Fixed: reg_types.h
Fixed: regex.h
Fixed: regexp.h
Fixed: rpc/auth.h
Fixed: rpc/rpc.h
Fixed: rpc/xdr.h
Fixed: rpcsvc/rstat.h
Fixed: rpcsvc/rusers.h
Fixed: rtldef/decc$types.h
Fixed: rtldef/if.h
Fixed: rtldef/resolv.h
Fixed: rtldef/setjmp.h
Fixed: rtldef/signal.h
Fixed: rtldef/stdio.h
Fixed: rtldef/string.h
Fixed: rtldef/wait.h
Fixed: setjmp.h
Fixed: signal.h
Fixed: sparc/asm_linkage.h
Fixed: spawn.h
Fixed: stdarg.h
Fixed: stdint-aix.h
Fixed: stdint-darwin.h
Fixed: stdint-hpux11.h
Fixed: stdint-newlib.h
Fixed: stdint.h
Fixed: stdio.h
Fixed: stdio_tag.h
Fixed: stdlib.h
Fixed: string.h
Fixed: strings.h
Fixed: sundev/vuid_event.h
Fixed: sunwindow/win_lock.h
Fixed: sym.h
Fixed: sys/_inttypes.h
Fixed: sys/cdefs.h
Fixed: sys/feature_tests.h
Fixed: sys/file.h
Fixed: sys/int_const.h
Fixed: sys/int_limits.h
Fixed: sys/machine.h
Fixed: sys/mman.h
Fixed: sys/pthread.h
Fixed: sys/signal.h
Fixed: sys/socket.h
Fixed: sys/spinlock.h
Fixed: sys/stat.h
Fixed: sys/sysmacros.h
Fixed: sys/time.h
Fixed: sys/types.h
Fixed: sys/ucontext.h
Fixed: sys/ucred.h
Fixed: sys/wait.h
Fixed: testing.h
Fixed: tgmath.h
Fixed: time.h
Fixed: tinfo.h
Fixed: types/vxTypesBase.h
Fixed: unistd.h
Newly fixed header: sys/ucred.h
There were fixinclude test FAILURES
make[2]: *** [Makefile:177: check] Error 1
make[2]: Leaving directory '/lustre/work/oppe/gcc_workdir/fixincludes'
make[1]: *** [Makefile:3795: check-fixincludes] Error 2
make[1]: Leaving directory '/lustre/work/oppe/gcc_workdir'
Makefile:2323: recipe for target 'do-check' failed
make: *** [do-check] Error 2
Thus the "make check" phase aborts at the beginning.
My configure line was:
${build_dir}/gcc-${ver}/configure\
--prefix=${install_dir}\
--with-gmp=${install_dir}\
--with-mpfr=${install_dir}\
--with-mpc=${install_dir}\
--with-isl=${install_dir}\
--disable-nls\
--disable-multilib\
--disable-libmpx\
--enable-languages=c,c++,fortran\
--with-gxx-include-dir=${install_dir}/include/g++\
--enable-__cxa_atexit
I am building on a Cray XC40 system with GLIBC version 2.22 and operating
system 4.4.103-6.38-default
Tom Oppe
-----Original Message-----
From: Geir Johansen [mailto:geir@xxxxxxxx]
Sent: Wednesday, March 6, 2019 5:45 PM
To: Oppe, Thomas C ERDC-RDE-ITL-MS Contractor <Thomas.C.Oppe@xxxxxxxxxxxxx>;
Bill Long <longb@xxxxxxxx>
Cc: Alan Minga <aminga@xxxxxxxx>
Subject: Re: GCC 8.3.0 build fails on Cray systems with an older
"/usr/include/sys/sdt.h" version
Using the provided configure command ("%{snos_prefix}" is the install
directory), the developer indicates that gcc/8.3.0 was able to build on a
SLES 11 system using gcc 4.3 and glibc 2.11.3.
-- Geir Johansen
On 03/06/2019 04:33 PM, Oppe, Thomas C ERDC-RDE-ITL-MS Contractor wrote:
> Bill,
>
> Thank you for the information. I will try the GCC configure command
> provided by Dr. Johansen.
>
> Does anyone have a recommendation for the GLIBC configure command? I
> am to the point where I can compile a sufficiently old GLIBC version,
> but after I install it somewhere in my $HOME directory, every UNIX
> command segfaults, even "ls".
>
> Tom Oppe
>
>
> -----Original Message-----
> From: Bill Long [mailto:longb@xxxxxxxx]
> Sent: Wednesday, March 06, 2019 11:28 AM
> To: Geir Johansen <geir@xxxxxxxx>
> Cc: Oppe, Thomas C ERDC-RDE-ITL-MS Contractor
> <Thomas.C.Oppe@xxxxxxxxxxxxx>; Alan Minga <aminga@xxxxxxxx>
> Subject: Re: GCC 8.3.0 build fails on Cray systems with an older
> "/usr/include/sys/sdt.h" version
>
>
>> On Mar 5, 2019, at 8:53 PM, Geir Johansen <geir@xxxxxxxx> wrote:
>>
>> Hello,
>> GCC 8.2.0 was released for Cray XC (CLE 6.0 release only) on December
>> 13,
> 2018. I t would be recommended that Cray XC PE 18.12 (or later) be
> installed as this would have GCC 8.2.0 and the Cray PE libraries will
> be supported for GCC 8.2.0.
>> The schedule for the release of GCC 8.3.0 is tentatively scheduled
>> for the
> May PE release.
>> The following command is used to build GCC for the Cray XC:
>> % ../%{name}-%{version}/configure --prefix=%{snos_prefix}
> --disable-nls --libdir=%{snos_prefix}/lib
> --enable-languages=c,c++,fortran
> --with-gxx-include-dir=%{snos_prefix}/include/g++
> --with-slibdir=%{snos_prefix}/lib --with-system-zlib --enable-shared
> --enable-__cxa_atexit --build=x86_64-suse-linux --with-ppl
> --with-cloog --disable-multilib
>
>
> Just a note that the person who provided the build command did manage
> to build GCC 8.3.0 five different ways: x86_64 sles11, sles12, sles15,
> and
> aarch64 sles12, sles15, and all were successful.
>
> Cheers,
> Bill
>
>
>> Thanks,
>>
>> On 03/05/2019 12:36 AM, Oppe, Thomas C ERDC-RDE-ITL-MS Contractor wrote:
>>> Dear Sirs:
>>>
>>> My interest in building GCC 8.3.0 was to port a GAMESS version to it.
>>> I like to use a high optimization level for GAMESS files and then
>>> back down on the few files that need a lower optimization level in
>>> order to pass the 47 tests that come with the distribution. Here is
>>> a
> summary of what I found.
>>> The problem seems to be due to a "/usr/include/sys/sdt.h" file that
>>> was
> too
>>> old, as described below. I used the latest GCC compiler available on
> each
>>> Cray system to do the build.
>>>
>>> Copper, XE6m, used gcc/6.3.0, build of 8.3.0 fails
>>>
>>> Onyx, XC40/50, used gcc/7.3.0, no problems building 8.3.0
>>>
>>> Marble, XC40/50, a Test Development System (TDS) for Onyx, used
>>> gcc/7.3.0, no problems
>>>
>>> Excalibur, XC40, used gcc/7.2.0, build of 8.3.0 fails
>>>
>>> M982, XC40, a TDS for Excalibur, used gcc/7.2.0, build of 8.3.0
>>> fails
>>>
>>> Conrad, XC40, used gcc/7.3.0, build of 8.3.0 fails
>>>
>>> Gordon, XC40, used gcc/6.3.0, build of 8.3.0 fails
>>>
>>> A-12, XC40, a TDS for Conrad and Gordon, used gcc/7.3.0, build of
>>> 8.3.0 fails
>>>
>>> None of our Crays has an 8.1 or 8.2 GCC compiler on it, so I cannot
>>> test the hypothesis that building with a GCC 8.x compiler will solve
>>> the
> problem.
>>> If I could ask you a favor, what configuration line do you use to
>>> build GCC on Cray systems? I use
>>>
>>> ${build_dir}/gcc-8.3.0/configure\
>>> --prefix=${install_dir}\
>>> --with-gmp=${install_dir}\
>>> --with-mpfr=${install_dir}\
>>> --with-mpc=${install_dir}\
>>> --with-isl=${install_dir}\
>>> --disable-nls\
>>> --disable-multilib\
>>> --enable-languages=c,c++,fortran\
>>> --with-gxx-include-dir=${install_dir}/include/g++\
>>> --enable-__cxa_atexit
>>>
>>> In trying to achieve the same number and types of GCC test failures
>>> across all of our systems, I use a lot of the same prerequisites
>>> codes, but I am having problems compiling and installing GNU libc, a
>>> big
> job in itself.
>>> Would you have any suggestions for the configure line for GNU libc?
>>> Here is what I found about which versions we have on all our systems
>>> and which GLIBC version can be compiled on our oldest Cray system,
>>> Copper, which is running Linux 3.0.101-0.47.106.11-default.
>>>
>>>
>>> GLIBC versions:
>>>
>>> A-12 Cray 2.11.3
>>> Agm114 SGI 2.17
>>> Aquamarine SGI 2.17
>>> Centennial SGI 2.17
>>> Conrad Cray 2.11.3
>>> Copper Cray 2.11.3
>>> Excalibur Cray 2.11.3
>>> FOB IBM 2.17
>>> Gaffney HPE 2.17
>>> Gordon Cray 2.11.3
>>> Hokulea IBM 2.17
>>> Koehr HPE 2.17
>>> M982 Cray 2.11.3
>>> Marble Cray 2.22
>>> Mustang HPE 2.17
>>> Onyx Cray 2.19
>>> Shadow HPE 2.17
>>> Spectre HPE 2.17
>>> Stockham SGI 2.17
>>> Thunder SGI
>>> Topaz SGI 2.11.3
>>> Toppe-dt Dell 2.17
>>> Voodoo HPE 2.17
>>> Yaw IBM 2.17
>>>
>>> GNU libc versions:
>>>
>>> 2.29 requires Linux 3.2.0 or later
>>> 2.28 requires Linux 3.2.0 or later
>>> 2.27 requires Linux 3.2.0 or later
>>> 2.26 requires Linux 3.2.0 or later
>>> 2.25 requires Linux 3.2.0 or later
>>> 2.24 requires Linux 3.2.0 or later
>>> 2.23 configure OK, but 3 compilation errors, bugfixed by me
>>>
>>> Tom Oppe
>>>
>>> -----Original Message-----
>>> From: Geir Johansen [
>>> mailto:geir@xxxxxxxx
>>> ]
>>> Sent: Monday, March 04, 2019 4:25 PM
>>> To: Bill Long
>>> <longb@xxxxxxxx>
>>> ; Oppe, Thomas C ERDC-RDE-ITL-MS Contractor
>>>
>>> <Thomas.C.Oppe@xxxxxxxxxxxxx>
>>>
>>> Cc: Alan Minga
>>> <aminga@xxxxxxxx>; Sean Palmer <srp@xxxxxxxx>
>>>
>>> Subject: Re: GCC 8.3.0 build fails on Cray systems with an older
>>> "/usr/include/sys/sdt.h" version
>>>
>>> Hello,
>>>
>>> Is this for a Cray XC? The latest Cray XC release version of GCC is
>>> currently 8.2.0. Is there a specific reason that 8.3.0 needs to be used
>>> instead of 8.2.0? GCC 8.3.0 will be released for Cray XC in the
>>> future, although its release date has not yet been determined.
>>>
>>> Bill's suggestion of loading gcc/8.2.0 to build GCC 8.3.0 does have
>>> a good chance of working.
>>>
>>> Thanks,
>>>
>>> Geir Johansen
>>>
>>> On 03/04/2019 03:53 PM, Bill Long wrote:
>>>
>>>> Hi Tom,
>>>>
>>>> Did you have GCC 8.1 or 8.2 loaded when you tried to do the build?
> I'm
>>> not really an expert on building GCC compilers. I've added Geir
>>> (the SPS C
>>> analyst) and Sean to the CC: list.
>>>
>>>> Cheers,
>>>> Bill
>>>>
>>>>
>>>>
>>>>> On Mar 2, 2019, at 2:20 AM, Oppe, Thomas C ERDC-RDE-ITL-MS
>>>>> Contractor
>>>>>
>>> <Thomas.C.Oppe@xxxxxxxxxxxxx>
>>> wrote:
>>>
>>>>> Dear Sir:
>>>>>
>>>>> My build of GCC 8.3.0 fails on certain Cray systems having an
>>>>> older "/usr/include/sys/sdt.h" file. The error messages are:
>>>>>
>>>>> In file included from
>>>>> /p/tds/work/oppe/gcc-8.3.0/libstdc++-v3/libsupc++/unwind-cxx.h:41,
>>>>> from
>>>>> /p/tds/work/oppe/gcc-8.3.0/libstdc++-v3/libsupc++/eh_catch.cc:26:
>>>>> /p/tds/work/oppe/gcc-8.3.0/libstdc++-v3/libsupc++/eh_catch.cc: In
>>>>> function
>>>>> 'void* __cxxabiv1::__cxa_begin_catch(void*)':
>>>>> /p/tds/work/oppe/gcc-8.3.0/libstdc++-v3/libsupc++/unwind-cxx.h:45:34:
>>>>>
>>> error:
>>>
>>>>> unable to find string literal operator 'operator""_SDT_S' with
>>>>> 'const char [37]', 'long unsigned int' arguments #define
>>>>> PROBE2(name, arg1,
>>>>> arg2) STAP_PROBE2 (libstdcxx, name, arg1, arg2)
>>>>> ^~~~~~~~~~~
>>>>> /p/tds/work/oppe/gcc-8.3.0/libstdc++-v3/libsupc++/eh_catch.cc:84:3:
>>>>> note: in expansion of macro 'PROBE2'
>>>>> PROBE2 (catch, objectp, header->exceptionType);
>>>>> ^~~~~~
>>>>> /p/tds/work/oppe/gcc-8.3.0/libstdc++-v3/libsupc++/unwind-cxx.h:45:34:
>>>>>
>>> error:
>>>
>>>>> unable to find string literal operator 'operator""_SDT_S' with
>>>>> 'const char [51]', 'long unsigned int' arguments #define
>>>>> PROBE2(name, arg1,
>>>>> arg2) STAP_PROBE2 (libstdcxx, name, arg1, arg2)
>>>>> ^~~~~~~~~~~
>>>>> /p/tds/work/oppe/gcc-8.3.0/libstdc++-v3/libsupc++/eh_catch.cc:84:3:
>>>>> note: in expansion of macro 'PROBE2'
>>>>> PROBE2 (catch, objectp, header->exceptionType);
>>>>> ^~~~~~
>>>>> make[5]: *** [eh_catch.lo] Error 1
>>>>> make[5]: Leaving directory
>>>>>
> `/p/tds/work/oppe/gcc_workdir/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++'
>>>>> make[4]: *** [all-recursive] Error 1
>>>>> make[4]: Leaving directory
>>>>> `/p/tds/work/oppe/gcc_workdir/x86_64-pc-linux-gnu/libstdc++-v3'
>>>>> make[3]: *** [all] Error 2
>>>>> make[3]: Leaving directory
>>>>> `/p/tds/work/oppe/gcc_workdir/x86_64-pc-linux-gnu/libstdc++-v3'
>>>>> make[2]: *** [all-stage1-target-libstdc++-v3] Error 2
>>>>> make[2]: Leaving directory `/p/tds/work/oppe/gcc_workdir'
>>>>> make[1]: *** [stage1-bubble] Error 2
>>>>> make[1]: Leaving directory `/p/tds/work/oppe/gcc_workdir'
>>>>> make: *** [all] Error 2
>>>>>
>>>>> I found a web page dealing with this problem:
>>>>>
>>>>>
>>>>> BlockedBlockedBlockedhttp://www.memoryhole.net/kyle/2013/04/buildi
>>>>> ng_gcc_4Blocked
>>>>> 8_on_rhelBlocked
>>>>>
>>>>> 58.htmlBlocked
>>>>>
>>>>> Maybe one solution is to modify a line in the file
>>>>>
>>>>> gcc-8.3.0/libstdc++-v3/config.h.in
>>>>>
>>>>> to edit the lines 436-7
>>>>>
>>>>> /* Define to 1 if you have a suitable <sys/sdt.h> header file */
>>>>> #undef HAVE_SYS_SDT_H
>>>>>
>>>>> and comment line 437
>>>>>
>>>>> /*#undef HAVE_SYS_SDT_H*/
>>>>>
>>>>> Is there a better solution than changing the GCC 8.3.0 tar file?
>>>>>
>>>>> Thank you.
>>>>>
>>>>> Tom Oppe
>>>>>
>>>>>
>>>> Bill Long
>>>>
>>> longb@xxxxxxxx
>>>> Principal Engineer, Fortran Technical Support & voice: 651-605-9024
>>>> Bioinformatics Software Development fax:
>>>>
>>> 651-605-9143
>>>
>>>> Cray Inc./ 2131 Lindau Lane/ Suite 1000/ Bloomington, MN 55425
>>>>
>>>>
>>>>
> Bill Long
> longb@xxxxxxxx
> Principal Engineer, Fortran Technical Support & voice: 651-605-9024
> Bioinformatics Software Development fax:
651-605-9143
> Cray Inc./ 2131 Lindau Lane/ Suite 1000/ Bloomington, MN 55425
>
>
>
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
