https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836
--- Comment #24 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot
Uni-Bielefeld.DE> ---
> --- Comment #23 from Gary Mills <gary_mills at fastmail dot fm> ---
> It's not Solaris, first of all. Solaris is a closed system once again. It's
> illumos, which is derived from Opensolaris. These are the two assemblers:
>
> This is on SPARC hardware:
> <mills@t2000:725>$ as -V
> as: Sun Compiler Common 12 SunOS_sparc snv_121 08/03/2009
> <mills@t2000:726>$ uname -a
> SunOS t2000 5.11 master-0-g5093b3b sun4v sparc SUNW,Sun-Fire-T200
>
> This is on x86 hardware:
> <mills@tyan:545>$ as -V
> as: Sun Compiler Common 12 SunOS_i386 snv_121 08/03/2009
> Usage: as [-V] [-Q{y,n}] [-s]
> [-S[aAbBcClL]] [-K {pic,PIC}] [-o objfile] [-L] [-T]
> [-P [[-Ipath] [-Dname] [-Dname=def] [-Uname]]...]
> [-m [-Ym,path]] [-n] [-xF] [-F] [-b] [-i] file.s ...
> <mills@tyan:546>$ uname -a
> SunOS tyan 5.11 illumos-8dfe5547fb i86pc i386 i86pc
as it happens, I still have copies of both assemblers from OpenSolaris
snv_147 BEs I still have around. Both are almost 10 years old by now,
way older than the oldest versions of as I test with:
ro@s10-sparc 11 > /usr/ccs/bin/as -V
/usr/ccs/bin/as: Studio 12.5 Compiler Common 12.5 SunOS_sparc Patch 05/02/2016
ro@s10-sparc 12 > /bin/uname -a
SunOS s10-sparc.gcc 5.10 Generic_150400-59 sun4v sparc sun4v
ro@zebrano 1 > /usr/ccs/bin/as -V
as: Studio 12.5 Compiler Common 12.5 SunOS_i386 Patch 03/07/2016
[...]
ro@zebrano 2 > /bin/uname -a
SunOS zebrano 5.10 Generic_150401-59 i86pc i386 i86pc
And with the removal of Solaris 10 support in GCC 10, even those soon
won't be tested any longer, Solaris 11.3 being the oldest version I'm
testing here.
> They seem to be the same. illumos does not have source for the assembler,
> only
They are not: sparc and x86 as are completely different code bases.
They are integrated into Solaris once in a while from the studio
consolidation, usually at the same time. Thus they get the same build
number (snv_121) at that time.
> the binaries. They can't be changed. illumos does have source for the
> linkers.
Overall, I wonder if pursuing this PR isn't a waste of all our time.
Both assemblers are almost 10 years old, and Solaris as has had its host
of problems. I've gotten some of them fixed over the years. It may be
more effective to just go for a recent gas instead.
> Yes, /usr/gcc/4.9/bin/gcc and /usr/gcc/4.9/bin/g++ are the 32-bit-default
> compilers. They will produce 64-bit binaries with the -m64 option. They are
> actually 4.9.4. I built the compilers myself, using gcc-4.4.4.
Good. I'm only asking since because we just had a problem with a
64-bit-default gcc used as a bootstrap compiler.
> I just tried a build of gcc-7 (gcc-7.3.0) with a minimal configuration. This
> is what appears in the oldest config.log:
>
> $
> /export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/gcc-7.3.0/configure
> CC=/usr/gcc/4.9/bin/gcc CXX=/usr/gcc/4.9/bin/g++ F77=/usr/gcc/4.9/bin/gfortran
> FC=/usr/gcc/4.9/bin/gfortran CFLAGS= -O3 -mno-app-regs CXXFLAGS= FFLAGS=
> FCFLAGS= LDFLAGS=-m32 PKG_CONFIG_PATH=/usr/lib/pkgconfig --prefix=/usr/gcc/7
> --mandir=/usr/gcc/7/share/man --bindir=/usr/gcc/7/bin --libdir=/usr/gcc/7/lib
> --sbindir=/usr/gcc/7/sbin --sbindir=/usr/gcc/7/bin --libdir=/usr/gcc/7/lib
> --libexecdir=/usr/gcc/7/lib --host sparc-sun-solaris2.11 --build
> sparc-sun-solaris2.11 --target sparc-sun-solaris2.11 --without-gnu-ld
> --with-ld=/usr/bin/ld --without-gnu-as --with-as=/usr/bin/as
> LDFLAGS=-R/usr/gcc/7/lib
Could you please for simplicity's sake omit almost everything above?
Just CC, CXX, --without-gnu-{as,ld} --with-{as,ld}=/usr/bin/{as,ld}
> I also removed all of the patches except for one that modifies
> libgcc/config.host to create crtbeginS.o and crtendS.o. The build stopped
> quite early with this error:
>
> /usr/gcc/4.9/bin/g++ -std=gnu++98 -g -DIN_GCC -fno-exceptions -fno-rtti
> -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
> -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual
> -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
> -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -static-libstdc++
> -static-libgcc -R/usr/gcc/7/lib -o build/genmddeps \
> build/genmddeps.o build/read-md.o build/errors.o
> ../build-sparc-sun-solaris2.11/libiberty/libiberty.a
> build/genmddeps
> /export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/gcc-7.3.0/gcc/common.md
> /export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/gcc-7.3.0/gcc/config/sparc/sparc.md
>> tmp-mddeps
> /bin/bash: line 1: 28485 Bus Error (core dumped) build/genmddeps
> /export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/gcc-7.3.0/gcc/common.md
> /export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/gcc-7.3.0/gcc/config/sparc/sparc.md
>> tmp-mddeps
> Makefile:2240: recipe for target 's-mddeps' failed
> make[4]: *** [s-mddeps] Error 138
> make[4]: Leaving directory
> '/dpool/export/home/mills/Downloads/code/oi-userland-apr/components/developer/gcc-7/build/sparcv7/gcc'
>
> This is what gdb said about the core file:
>
> (gdb) bt
> #0 0x0001f7bc in __gnu_cxx::__mutex::__mutex (
> this=0x5007c <(anonymous namespace)::emergency_mutex>)
> at
> /export/home/mills/Downloads/code/oi-userland/components/developer/gcc49/build/sparcv7/sparc-sun-solaris2.11/libstdc++-v3/include/ext/concurrence.h:132
> #1 __static_initialization_and_destruction_0 (__priority=65535,
> __initialize_p=1)
> at
> /export/home/mills/Downloads/code/oi-userland/components/developer/gcc49/gcc-4.9.4/libstdc++-v3/libsupc++/eh_alloc.cc:96
> #2 _GLOBAL__sub_I_eh_alloc.cc(void) ()
> at
> /export/home/mills/Downloads/code/oi-userland/components/developer/gcc49/gcc-4.9.4/libstdc++-v3/libsupc++/eh_alloc.cc:211
> #3 0x0002f19c in __do_global_ctors_aux ()
> #4 0x0002f1d4 in _init ()
> #5 0x000165f0 in _start ()
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> (gdb) quit
>
> The build didn't dump core at this point before. Something in the
> configuration must have changed its behavior.
But that's code generated by the bootstrap compiler, which is why I
asked to start with a vanilla build of gcc 4.9.
I may try a build on Solaris 10 with the snv_121 assembler myself.
The sparc machine is busy until tomorrow night; I may try a Solaris
10/x86 build instead since you say you're seeing the same error there.
