Problem bootstrapping gcc-3.3.1 (snapshot) on Sparc Solaris2.8

Problem bootstrapping gcc-3.3.1 (snapshot) on Sparc Solaris2.8

[Josh]

I've configured with the following options in a separate objects directory (gcc-objs), using gcc-3.2.3 as the starting compiler:
../gcc-3.3/configure --prefix=/compiler/gcc-3.3 \
--with-ld=/compiler/gcc-3.2.3/bin/ld
--with-gnu-ld \
--with-as=compiler/gcc-3.2.3/bin/as \
--with-gnu-as \
--disable-nls \
--enable-threads=posix

Then:
make CFLAGS='-O' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2 -fno-implicit-templates' boostrap-lean

The build goes through, completes stage3 compiler, then the following error in eh_alloc.cc:

/home/fird3/gcc-objs/gcc/xgcc -shared-libgcc -B/home/fird3/gcc-objs/gcc/ -nostdinc++ -L/home/fird3/gcc-objs/spar
c-sun-solaris2.8/sparcv9/libstdc++-v3/src -L/home/fird3/gcc-objs/sparc-sun-solaris2.8/sparcv9/libstdc++-v3/src/.
libs -B/prod/fir/compile/sol8/gcc-3.3/sparc-sun-solaris2.8/bin/ -B/prod/fir/compile/sol8/gcc-3.3/sparc-sun-solar
is2.8/lib/ -isystem /prod/fir/compile/sol8/gcc-3.3/sparc-sun-solaris2.8/include -m64 -I../../../../../gcc-200305
19/libstdc++-v3/../gcc -I../../../../../gcc-20030519/libstdc++-v3/../include -I/home/fird3/gcc-objs/sparc-sun-so
laris2.8/sparcv9/libstdc++-v3/include/sparc-sun-solaris2.8 -I/home/fird3/gcc-objs/sparc-sun-solaris2.8/sparcv9/l
ibstdc++-v3/include -I../../../../../gcc-20030519/libstdc++-v3/libsupc++ -g -O2 -m64 -fno-implicit-templates -Wa
ll -Wno-format -W -Wwrite-strings -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -c ../../
../../../gcc-20030519/libstdc++-v3/libsupc++/eh_aux_runtime.cc  -fPIC -DPIC -o eh_aux_runtime.o
../../../../../gcc-20030519/libstdc++-v3/libsupc++/eh_alloc.cc:81: error: too
   many initializers for `_pthread_mutex::<anonymous struct>'
make[7]: *** [eh_alloc.lo] Error 1
make[7]: *** Waiting for unfinished jobs....
make[7]: Leaving directory `/home/fird3/gcc-objs/sparc-sun-solaris2.8/sparcv9/libstdc++-v3/libsupc++'
make[6]: *** [all-recursive] Error 1
make[6]: Leaving directory `/home/fird3/gcc-objs/sparc-sun-solaris2.8/sparcv9/libstdc++-v3'
make[5]: *** [all-recursive-am] Error 2
make[5]: Leaving directory `/home/fird3/gcc-objs/sparc-sun-solaris2.8/sparcv9/libstdc++-v3'
make[4]: *** [multi-do] Error 1
make[4]: Leaving directory `/home/fird3/gcc-objs/sparc-sun-solaris2.8/libstdc++-v3'
make[3]: *** [all-multi] Error 2
make[3]: Leaving directory `/home/fird3/gcc-objs/sparc-sun-solaris2.8/libstdc++-v3'
make[2]: *** [all-recursive-am] Error 2
make[2]: Leaving directory `/home/fird3/gcc-objs/sparc-sun-solaris2.8/libstdc++-v3'
make[1]: *** [all-target-libstdc++-v3] Error 2
make[1]: Leaving directory `/home/fird3/gcc-objs'
make: *** [bootstrap-lean] Error 2


Any insights?  I tried configuring w/ --enable-threads=single, but that also fails.  Thanks in advance.

Regards,
Josh

macros to detect endiannes?

[Kimmo Fredriksson]

Hi,

I have some source that makes assumptions on the endiannes of the
architecture. To make it more portable I'd like write specific code for
both little and big endian machines. Are there any predefined macros that
could be used to detect the endiannes at compile time, that I could use in
conditional compilation?

Thanks,

kf

RE: macros to detect endiannes?

[Rupert Wood]

Kimmo Fredriksson wrote:

> Are there any predefined macros that could be used to detect the
> endiannes at compile time, that I could use in conditional
> compilation?

No, not by default. If your project uses autoconf you can use macro
AC_C_BIGENDIAN to create a define in the generated config.h; see the manual
and the 'autobook':

    http://www.gnu.org/manual/autoconf/autoconf.html
    http://sources.redhat.com/autobook/

If you're compiling for a large set of platforms you should really consider
autoconf etc.; if you're only compiling for a small set you can test for
platform specific defines (e.g. _WIN32 and _M_IX86 or __sun__) and then make
your own defines and #error if nothing matches.

Rup.

Re: macros to detect endiannes?

[Eljay Love-Jensen]

Hi Kimmo,

GCC is a very good optimizing compiler.  A very, very good optimizing compiler.

Before you invest in making endian-aware subroutines, I strongly urge you to consider writing endian-agnostic routines.

And if code profiling IN THE OPTIMIZED CODE bears out that those routines need to be & can be made more efficient by being crafted as endian-aware routines, then-and-only-then take the next step by writing non-portable endian-aware code.

Even if the portability is subsumed by macro-triggers of endian-ness to preprocess-in the correct endian-aware code, that code is still less-than-portable.

Also the big-endian and little-endian code needs to be maintained in tandem.  That can be a source of problems, via code rot.

KISS is applicable in situations like these.  Tricky is not necessarily better.  Nor necessarily more efficient.

Sincerely,
--Eljay

More insights at <http://mindprod.com/unmain.html>.