the struggle for a 64-bit GCC on Solaris 10 - part 2

the struggle for a 64-bit GCC on Solaris 10 - part 2

[Dennis Clarke]

[ note : correctly posted in gcc-help ]

After many a foolish mistake and even a few blunt trauma foul ups on my part I seem 
to have this process moving along. The magic incantations required appear to be to 
specify environment variables for CC and CXX on the very command line that "configure" 
is also on.  As well as a correct magic "triplet". Odd, given that many environment variables
for CC and CXX as well as CFLAGS and CXXFLAGS are already defined in the env vars.
Regardless the following configure for GCC 4.7.2 resulted in an error : 

$ pwd
/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou  <-- pay homage to the wizards here :-)

$ CC='gcc -m64' CXX='g++ -m64' ../gcc-4.7.2/configure --prefix=/usr/local/gcc4 \
> --build=sparc64-sun-solaris2.10 --without-gnu-as --without-gnu-ld \
> --with-gmp=/usr/local --with-mpfr=/usr/local --with-mpc=/usr/local \
> --with-ld=/usr/ccs/bin/ld --enable-nls --enable-threads=posix --enable-shared \
> --libdir=/usr/local/gcc4/lib --with-local-prefix=/usr/local/gcc4 \
> --with-cpu=v9 --enable-stage1-languages=c --disable-multilib \
> --libexecdir=/usr/local/gcc4/lib \
> --with-pkgversion=Blastwave.org\ Inc.\ Mon\ Nov\ 12\ 04\:18\:15\ GMT\ 2012 \
> --with-bugurl=http\:\/\/www.blastwave.org\/support \
> --enable-languages=c,c++,objc,fortran,ada --enable-bootstrap
checking build system type... sparc64-sun-solaris2.10
checking host system type... sparc64-sun-solaris2.10
checking target system type... sparc64-sun-solaris2.10
checking for a BSD-compatible install... ../gcc-4.7.2/install-sh -c
checking whether ln works... yes
checking whether ln -s works... yes
checking for a sed that does not truncate output... /usr/local/bin/gsed
checking for gawk... gawk
checking for libitm support... yes
checking for gcc... gcc -m64
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... 
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc -m64 accepts -g... yes
checking for gcc -m64 option to accept ISO C89... none needed
checking whether we are using the GNU C++ compiler... yes
checking whether g++ -m64 accepts -g... yes
checking for gnatbind... gnatbind
checking for gnatmake... gnatmake
checking whether compiler driver understands Ada... yes
checking how to compare bootstrapped objects... cmp $$f1 $$f2 16 16
checking for objdir... .libs
checking for the correct version of gmp.h... yes
checking for the correct version of mpfr.h... yes
checking for the correct version of mpc.h... yes
checking for the correct version of the gmp/mpfr/mpc libraries... yes
checking for PWL_handle_timeout in -lpwl... no
checking for version 0.11 (revision 0 or later) of PPL... no
The following languages will be built: c,ada,c++,fortran,lto,objc
*** This configuration is not supported in the following subdirectories:
     target-libmudflap target-libgo target-libffi target-zlib target-libjava target-boehm-gc
    (Any other directories should still work fine.)
checking for default BUILD_CONFIG... 
checking for bison... bison -y
checking for bison... bison
checking for gm4... /usr/local/bin/gm4
checking for flex... flex
checking for flex... flex
checking for makeinfo... makeinfo
checking for expect... expect
checking for runtest... runtest
checking for ar... (cached) /usr/ccs/bin/ar
checking for as... (cached) /usr/ccs/bin/as
checking for dlltool... no
checking for ld... (cached) /usr/ccs/bin/ld
checking for lipo... no
checking for nm... nm
checking for ranlib... ranlib
checking for strip... strip
checking for windres... no
checking for windmc... no
checking for objcopy... no
checking for objdump... no
checking for readelf... no
checking for cc... cc
checking for c++... c++
checking for gcc... gcc
checking for gcj... no
checking for gfortran... gfortran
checking for gccgo... no
checking for ar... no
checking for ar... ar
checking for as... no
checking for as... as
checking for dlltool... no
checking for dlltool... no
checking for ld... no
checking for ld... ld
checking for lipo... no
checking for lipo... no
checking for nm... no
checking for nm... nm
checking for objdump... no
checking for objdump... no
checking for ranlib... no
checking for ranlib... ranlib
checking for readelf... no
checking for readelf... no
checking for strip... no
checking for strip... strip
checking for windres... no
checking for windres... no
checking for windmc... no
checking for windmc... no
checking where to find the target ar... host tool
checking where to find the target as... host tool
checking where to find the target cc... just compiled
checking where to find the target c++... just compiled
checking where to find the target c++ for libstdc++... just compiled
checking where to find the target dlltool... host tool
checking where to find the target gcc... just compiled
checking where to find the target gcj... host tool
checking where to find the target gfortran... just compiled
checking where to find the target gccgo... host tool
checking where to find the target ld... host tool
checking where to find the target lipo... host tool
checking where to find the target nm... host tool
checking where to find the target objdump... host tool
checking where to find the target ranlib... host tool
checking where to find the target readelf... host tool
checking where to find the target strip... host tool
checking where to find the target windres... host tool
checking where to find the target windmc... host tool
checking whether to enable maintainer-specific portions of Makefiles... no
checking whether -fkeep-inline-functions is supported... yes
configure: creating ./config.status
config.status: creating Makefile
$ 

then fire off a "/usr/bin/time -p gmake" and wait .. a long long time later in stage 2 I see : 

.
.
.
 /usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou/./prev-gcc/g++ -B/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou/./prev-gcc/ -B/usr/local/gcc4/sparc64-sun-solaris2.10/bin/ -nostdinc++ -B/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou/prev-sparc64-sun-solaris2.10/libstdc++-v3/src/.libs -B/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou/prev-sparc64-sun-solaris2.10/libstdc++-v3/libsupc++/.libs -I/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou/prev-sparc64-sun-solaris2.10/libstdc++-v3/include/sparc64-sun-solaris2.10 -I/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou/prev-sparc64-sun-solaris2.10/libstdc++-v3/include -I/usr/local/build/gcc-4.7.2/libstdc++-v3/libsupc++ -L/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou/prev-sparc64-sun-solaris2.10/libstdc++-v3/src/.libs -L/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou/prev-sparc64-sun-solaris2.10/libstdc++-v3/libsupc++/.libs -c  
 -g -O2 -DIN_GCC   -fno-exceptions -fno-rtti -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.7.2/gcc -I../../gcc-4.7.2/gcc/. -I../../gcc-4.7.2/gcc/../include -I./../intl -I../../gcc-4.7.2/gcc/../libcpp/include -I/usr/local/include -I/usr/local/include -I/usr/local/include  -I../../gcc-4.7.2/gcc/../libdecnumber -I../../gcc-4.7.2/gcc/../libdecnumber/dpd -I../libdecnumber   -I/usr/local/include:/opt/csw/gcc4/include ../../gcc-4.7.2/gcc/diagnostic.c -o diagnostic.o
/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou/./prev-gcc/g++ -B/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou/./prev-gcc/ -B/usr/local/gcc4/sparc64-sun-solaris2.10/bin/ -nostdinc++ -B/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou/prev-sparc64-sun-solaris2.10/libstdc++-v3/src/.libs -B/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou/prev-sparc64-sun-solaris2.10/libstdc++-v3/libsupc++/.libs -I/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou/prev-sparc64-sun-solaris2.10/libstdc++-v3/include/sparc64-sun-solaris2.10 -I/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou/prev-sparc64-sun-solaris2.10/libstdc++-v3/include -I/usr/local/build/gcc-4.7.2/libstdc++-v3/libsupc++ -L/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou/prev-sparc64-sun-solaris2.10/libstdc++-v3/src/.libs -L/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou/prev-sparc64-sun-solaris2.10/libstdc++-v3/libsupc++/.libs -c   
-g -O2 -DIN_GCC   -fno-exceptions -fno-rtti -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.7.2/gcc -I../../gcc-4.7.2/gcc/. -I../../gcc-4.7.2/gcc/../include -I./../intl -I../../gcc-4.7.2/gcc/../libcpp/include -I/usr/local/include -I/usr/local/include -I/usr/local/include  -I../../gcc-4.7.2/gcc/../libdecnumber -I../../gcc-4.7.2/gcc/../libdecnumber/dpd -I../libdecnumber   -I/usr/local/include:/opt/csw/gcc4/include ../../gcc-4.7.2/gcc/pretty-print.c -o pretty-print.o
../../gcc-4.7.2/gcc/pretty-print.c: In function 'const char* identifier_to_locale(const char*)':
../../gcc-4.7.2/gcc/pretty-print.c:954:28: error: invalid conversion from 'char**' to 'const char**' [-fpermissive]
gmake[3]: *** [pretty-print.o] Error 1
gmake[3]: Leaving directory `/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou/gcc'
gmake[2]: *** [all-stage2-gcc] Error 2
gmake[2]: Leaving directory `/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou'
gmake[1]: *** [stage2-bubble] Error 2
gmake[1]: Leaving directory `/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou'
gmake: *** [all] Error 2

real 27941.42
user 24133.86
sys 713.93


$ cat stage_current
stage2

It looks as if stage 1 was finished and then somewhere in stage 2 we get a C error in gcc/pretty-print.c.

Anyone have any thoughts on this one ? 

Dennis 

ps: I did try to use the wizard like incantations that have things like --with-{gmp,mpfr,mpc}=/usr/local on the configure line, 
however that was seen as an error .. or simply not understood by "configure" : 

$ CC='gcc -m64' CXX='g++ -m64' ../gcc-4.7.2/configure --prefix=/usr/local/gcc4 \
> --build=sparc64-sun-solaris2.10 --without-gnu-{as,ld} --with-{gmp,mpfr,mpc}=/usr/local \
> --with-ld=/usr/ccs/bin/ld --enable-nls --enable-threads=posix --enable-shared \
> --libdir=/usr/local/gcc4/lib --with-local-prefix=/usr/local/gcc4 \
> --with-cpu=v9 --enable-stage1-languages=c --disable-multilib \
> --libexecdir=/usr/local/gcc4/lib \
> --with-pkgversion=Blastwave.org\ Inc.\ Mon\ Nov\ 12\ 04\:18\:15\ GMT\ 2012 \
> --with-bugurl=http\:\/\/www.blastwave.org\/support \
> --enable-languages=c,c++,objc,fortran,ada --enable-bootstrap
configure: error: invalid package name: gnu-{as,ld}

Re: the struggle for a 64-bit GCC on Solaris 10 - part 2

[Ryan Johnson]

On 12/11/2012 11:10 AM, Dennis Clarke wrote:
> ps: I did try to use the wizard like incantations that have things like --with-{gmp,mpfr,mpc}=/usr/local on the configure line,
> however that was seen as an error .. or simply not understood by "configure" :
Bash expands {a,b}-{c,d} to "ab ac bc bd"; if you use a different shell, 
you'll have to type it out manually.

Ryan

Re: the struggle for a 64-bit GCC on Solaris 10 - part 2

[Dennis Clarke]

> On 12/11/2012 11:10 AM, Dennis Clarke wrote:
> > ps: I did try to use the wizard like incantations that have things 
> like --with-{gmp,mpfr,mpc}=/usr/local on the configure line,
> > however that was seen as an error .. or simply not understood by 
> "configure" :
> Bash expands {a,b}-{c,d} to "ab ac bc bd"; if you use a different 
> shell, 
> you'll have to type it out manually.

saw that.  Most linux people always asssume bash is the shell and it often leads to 
problems with piles of gnu projects. Many scripts in gnu software projects have "#! /bin/sh" in
them and then proceed with bash-ness and then fail on an OS where /bin/sh really is just 
the bourne shell.  I see it, all the time.

On other fronts, any thoughts on :

../../gcc-4.7.2/gcc/pretty-print.c: In function 'const char* identifier_to_locale(const char*)':
../../gcc-4.7.2/gcc/pretty-print.c:954:28: error: invalid conversion from 'char**' to 'const char**' [-fpermissive]
gmake[3]: *** [pretty-print.o] Error 1
gmake[3]: Leaving directory `/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou/gcc'
gmake[2]: *** [all-stage2-gcc] Error 2
gmake[2]: Leaving directory `/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou'
gmake[1]: *** [stage2-bubble] Error 2
gmake[1]: Leaving directory `/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou'
gmake: *** [all] Error 2

?

dc

Re: the struggle for a 64-bit GCC on Solaris 10 - part 2

[Ian Lance Taylor]

On Mon, Nov 12, 2012 at 8:10 AM, Dennis Clarke <dclarke@blastwave.org> wrote:
>
> /usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou/./prev-gcc/g++ -B/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou/./prev-gcc/ -B/usr/local/gcc4/sparc64-sun-solaris2.10/bin/ -nostdinc++ -B/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou/prev-sparc64-sun-solaris2.10/libstdc++-v3/src/.libs -B/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou/prev-sparc64-sun-solaris2.10/libstdc++-v3/libsupc++/.libs -I/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou/prev-sparc64-sun-solaris2.10/libstdc++-v3/include/sparc64-sun-solaris2.10 -I/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou/prev-sparc64-sun-solaris2.10/libstdc++-v3/include -I/usr/local/build/gcc-4.7.2/libstdc++-v3/libsupc++ -L/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou/prev-sparc64-sun-solaris2.10/libstdc++-v3/src/.libs -L/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou/prev-sparc64-sun-solaris2.10/libstdc++-v3/libsupc++/.libs -c
> -g -O2 -DIN_GCC   -fno-exceptions -fno-rtti -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.7.2/gcc -I../../gcc-4.7.2/gcc/. -I../../gcc-4.7.2/gcc/../include -I./../intl -I../../gcc-4.7.2/gcc/../libcpp/include -I/usr/local/include -I/usr/local/include -I/usr/local/include  -I../../gcc-4.7.2/gcc/../libdecnumber -I../../gcc-4.7.2/gcc/../libdecnumber/dpd -I../libdecnumber   -I/usr/local/include:/opt/csw/gcc4/include ../../gcc-4.7.2/gcc/pretty-print.c -o pretty-print.o
> ../../gcc-4.7.2/gcc/pretty-print.c: In function 'const char* identifier_to_locale(const char*)':
> ../../gcc-4.7.2/gcc/pretty-print.c:954:28: error: invalid conversion from 'char**' to 'const char**' [-fpermissive]
> gmake[3]: *** [pretty-print.o] Error 1


Looks a lot like http://gcc.gnu.org/PR49794 , although that is said to
have been fixed in 4.7.  Other than that I don't know, but it may
suggest the people to talk to.

Ian

Re: the struggle for a 64-bit GCC on Solaris 10 - part 2

[Dennis Clarke]

> On Mon, Nov 12, 2012 at 8:10 AM, Dennis Clarke <dclarke@blastwave.org> 
> wrote:
> >
> > 
> /usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou/./prev-gcc/g++ 
> -B/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou/./prev-gcc/ 
> -B/usr/local/gcc4/sparc64-sun-solaris2.10/bin/ -nostdinc++ 
> -B/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou/prev-sparc64-sun-solaris2.10/libstdc++-v3/src/.libs 
> -B/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou/prev-sparc64-sun-solaris2.10/libstdc++-v3/libsupc++/.libs 
> -I/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou/prev-sparc64-sun-solaris2.10/libstdc++-v3/include/sparc64-sun-solaris2.10 
> -I/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou/prev-sparc64-sun-solaris2.10/libstdc++-v3/include 
> -I/usr/local/build/gcc-4.7.2/libstdc++-v3/libsupc++ 
> -L/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou/prev-sparc64-sun-solaris2.10/libstdc++-v3/src/.libs 
> -L/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou/prev-sparc64-sun-solaris2.10/libstdc++-v3/libsupc++/.libs 
> -c
> > -g -O2 -DIN_GCC   -fno-exceptions -fno-rtti -W -Wall -Wno-narrowing 
> -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic 
> -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   
> -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.7.2/gcc -I../../gcc-4.7.2/gcc/. 
> -I../../gcc-4.7.2/gcc/../include -I./../intl 
> -I../../gcc-4.7.2/gcc/../libcpp/include -I/usr/local/include 
> -I/usr/local/include -I/usr/local/include  
> -I../../gcc-4.7.2/gcc/../libdecnumber 
> -I../../gcc-4.7.2/gcc/../libdecnumber/dpd -I../libdecnumber   
> -I/usr/local/include:/opt/csw/gcc4/include 
> ../../gcc-4.7.2/gcc/pretty-print.c -o pretty-print.o
> > ../../gcc-4.7.2/gcc/pretty-print.c: In function 'const char* 
> identifier_to_locale(const char*)':
> > ../../gcc-4.7.2/gcc/pretty-print.c:954:28: error: invalid conversion 
> from 'char**' to 'const char**' [-fpermissive]
> > gmake[3]: *** [pretty-print.o] Error 1
> 
> 
> Looks a lot like http://gcc.gnu.org/PR49794 , although that is said to
> have been fixed in 4.7.  Other than that I don't know, but it may
> suggest the people to talk to.

  * sigh *

After all this struggle just to get to a bootstrap I am stopped by a bug. In a released GCC version
no less. Welcome to Solaris ... a rapidly shrinking market share OS where not much seems to 
work anymore. 

[ end of whine ] 

I'll reach out to Rainer and see what he thinks. Maybe I need to bootstrap a 4.6 version and then
maybe try to bootstrap 4.7 with that. Or revert back to Solaris 8 which always seemsed to work
well. 

Thanks for the pointers.

Dennis 

Re: the struggle for a 64-bit GCC on Solaris 10 - part 2

[Ryan Johnson]

On 12/11/2012 4:00 PM, Dennis Clarke wrote:
>> On Mon, Nov 12, 2012 at 8:10 AM, Dennis Clarke <dclarke@blastwave.org>
>> wrote:
>>>
>> /usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou/./prev-gcc/g++
>> -B/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou/./prev-gcc/
>> -B/usr/local/gcc4/sparc64-sun-solaris2.10/bin/ -nostdinc++
>> -B/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou/prev-sparc64-sun-solaris2.10/libstdc++-v3/src/.libs
>> -B/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou/prev-sparc64-sun-solaris2.10/libstdc++-v3/libsupc++/.libs
>> -I/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou/prev-sparc64-sun-solaris2.10/libstdc++-v3/include/sparc64-sun-solaris2.10
>> -I/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou/prev-sparc64-sun-solaris2.10/libstdc++-v3/include
>> -I/usr/local/build/gcc-4.7.2/libstdc++-v3/libsupc++
>> -L/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou/prev-sparc64-sun-solaris2.10/libstdc++-v3/src/.libs
>> -L/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou/prev-sparc64-sun-solaris2.10/libstdc++-v3/libsupc++/.libs
>> -c
>>> -g -O2 -DIN_GCC   -fno-exceptions -fno-rtti -W -Wall -Wno-narrowing
>> -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic
>> -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
>> -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.7.2/gcc -I../../gcc-4.7.2/gcc/.
>> -I../../gcc-4.7.2/gcc/../include -I./../intl
>> -I../../gcc-4.7.2/gcc/../libcpp/include -I/usr/local/include
>> -I/usr/local/include -I/usr/local/include
>> -I../../gcc-4.7.2/gcc/../libdecnumber
>> -I../../gcc-4.7.2/gcc/../libdecnumber/dpd -I../libdecnumber
>> -I/usr/local/include:/opt/csw/gcc4/include
>> ../../gcc-4.7.2/gcc/pretty-print.c -o pretty-print.o
>>> ../../gcc-4.7.2/gcc/pretty-print.c: In function 'const char*
>> identifier_to_locale(const char*)':
>>> ../../gcc-4.7.2/gcc/pretty-print.c:954:28: error: invalid conversion
>> from 'char**' to 'const char**' [-fpermissive]
>>> gmake[3]: *** [pretty-print.o] Error 1
>>
>> Looks a lot like http://gcc.gnu.org/PR49794 , although that is said to
>> have been fixed in 4.7.  Other than that I don't know, but it may
>> suggest the people to talk to.
>    * sigh *
>
> After all this struggle just to get to a bootstrap I am stopped by a bug.
I'm still really unclear on why you're having so much trouble with this. 
Have you tried bootstrapping with SunCC like I did? Granted, I'm only on 
5.9, but if newer versions fall down that's Oracle's fault, not gcc's.

Ryan

Re: the struggle for a 64-bit GCC on Solaris 10 - part 2

[Dennis Clarke]

> On 12/11/2012 4:00 PM, Dennis Clarke wrote:
> >> On Mon, Nov 12, 2012 at 8:10 AM, Dennis Clarke <dclarke@blastwave.org>
> >> wrote:
> >>>
> >> /usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou/./prev-gcc/g++
> >> -B/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou/./prev-gcc/
> >> -B/usr/local/gcc4/sparc64-sun-solaris2.10/bin/ -nostdinc++
> >> -B/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou/prev-sparc64-sun-solaris2.10/libstdc++-v3/src/.libs
> >> -B/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou/prev-sparc64-sun-solaris2.10/libstdc++-v3/libsupc++/.libs
> >> -I/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou/prev-sparc64-sun-solaris2.10/libstdc++-v3/include/sparc64-sun-solaris2.10
> >> -I/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou/prev-sparc64-sun-solaris2.10/libstdc++-v3/include
> >> -I/usr/local/build/gcc-4.7.2/libstdc++-v3/libsupc++
> >> -L/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou/prev-sparc64-sun-solaris2.10/libstdc++-v3/src/.libs
> >> -L/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10.ebotcazou/prev-sparc64-sun-solaris2.10/libstdc++-v3/libsupc++/.libs
> >> -c
> >>> -g -O2 -DIN_GCC   -fno-exceptions -fno-rtti -W -Wall -Wno-narrowing
> >> -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic
> >> -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
> >> -DHAVE_CONFIG_H -I. -I. -I../../gcc-4.7.2/gcc -I../../gcc-4.7.2/gcc/.
> >> -I../../gcc-4.7.2/gcc/../include -I./../intl
> >> -I../../gcc-4.7.2/gcc/../libcpp/include -I/usr/local/include
> >> -I/usr/local/include -I/usr/local/include
> >> -I../../gcc-4.7.2/gcc/../libdecnumber
> >> -I../../gcc-4.7.2/gcc/../libdecnumber/dpd -I../libdecnumber
> >> -I/usr/local/include:/opt/csw/gcc4/include
> >> ../../gcc-4.7.2/gcc/pretty-print.c -o pretty-print.o
> >>> ../../gcc-4.7.2/gcc/pretty-print.c: In function 'const char*
> >> identifier_to_locale(const char*)':
> >>> ../../gcc-4.7.2/gcc/pretty-print.c:954:28: error: invalid conversion
> >> from 'char**' to 'const char**' [-fpermissive]
> >>> gmake[3]: *** [pretty-print.o] Error 1
> >>
> >> Looks a lot like http://gcc.gnu.org/PR49794 , although that is said 
> to
> >> have been fixed in 4.7.  Other than that I don't know, but it may
> >> suggest the people to talk to.
> >    * sigh *
> >
> > After all this struggle just to get to a bootstrap I am stopped by a 
> bug.
> I'm still really unclear on why you're having so much trouble with 
> this. 
> Have you tried bootstrapping with SunCC like I did? Granted, I'm only 
> on 
> 5.9, but if newer versions fall down that's Oracle's fault, not gcc's.

Since this is a purely gcc 4.7.2 bootstrapped with gcc 4.5.1 as the compiler then it would be
entirely in GCC land and not Oracle. 

Regardless, I have reached out to Rainer Orth and hope to hear back from him.

Dennis 

ps: also .. I will try this on Solaris 8 which has always worked in the past.

Re: the struggle for a 64-bit GCC on Solaris 10 - part 2

[Jonathan Wakely]

On 12 November 2012 21:20, Dennis Clarke wrote:
>
>> I'm still really unclear on why you're having so much trouble with
>> this.
>> Have you tried bootstrapping with SunCC like I did? Granted, I'm only
>> on
>> 5.9, but if newer versions fall down that's Oracle's fault, not gcc's.
>
> Since this is a purely gcc 4.7.2 bootstrapped with gcc 4.5.1 as the compiler then it would be
> entirely in GCC land and not Oracle.

Except that the system headers which declare the problem function come
from Oracle.  And that doesn't answer the question.

Re: the struggle for a 64-bit GCC on Solaris 10 - part 2

[Marc Glisse]

On Mon, 12 Nov 2012, Ryan Johnson wrote:

> I'm still really unclear on why you're having so much trouble with this. Have 
> you tried bootstrapping with SunCC like I did?

I assume you mean suncc. gcc's code contains some C++ bugs that mean 
that Oracle's C++ compiler won't compile it (a bit of an issue for 4.8).

-- 
Marc Glisse

Re: the struggle for a 64-bit GCC on Solaris 10 - part 2

[Dennis Clarke]

----- Original Message -----
From: Jonathan Wakely <jwakely.gcc@gmail.com>
Date: Monday, November 12, 2012 4:26 pm
Subject: Re: the struggle for a 64-bit GCC on Solaris 10 - part 2
To: Dennis Clarke <dclarke@blastwave.org>
Cc: Ryan Johnson <ryan.johnson@cs.utoronto.ca>, Ian Lance Taylor <iant@google.com>, gcc-help@gcc.gnu.org, ebotcazou@adacore.com


> On 12 November 2012 21:20, Dennis Clarke wrote:
> >
> >> I'm still really unclear on why you're having so much trouble with
> >> this.
> >> Have you tried bootstrapping with SunCC like I did? Granted, I'm only
> >> on
> >> 5.9, but if newer versions fall down that's Oracle's fault, not gcc's.
> >
> > Since this is a purely gcc 4.7.2 bootstrapped with gcc 4.5.1 as the 
> compiler then it would be
> > entirely in GCC land and not Oracle.
> 
> Except that the system headers which declare the problem function come
> from Oracle.  And that doesn't answer the question.

No .. I have gone digging to see what is going on in there but it is deep, wide and dark. 

I did file a bug report : 

    http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55293

I hope I don't have to go fire up my old Solaris 8 server but, it did always result in a good looking GCC bootstrap. 

Dennis 

Re: the struggle for a 64-bit GCC on Solaris 10 - part 2

[Ryan Johnson]

On 12/11/2012 4:28 PM, Marc Glisse wrote:
> On Mon, 12 Nov 2012, Ryan Johnson wrote:
>
>> I'm still really unclear on why you're having so much trouble with 
>> this. Have you tried bootstrapping with SunCC like I did?
>
> I assume you mean suncc. gcc's code contains some C++ bugs that mean 
> that Oracle's C++ compiler won't compile it (a bit of an issue for 4.8).
>
Right... officially it's "Sun C" (as opposed to "Sun C++").

Re: the struggle for a 64-bit GCC on Solaris 10 - part 2

[Dennis Clarke]

----- Original Message -----
From: Marc Glisse <marc.glisse@inria.fr>
Date: Monday, November 12, 2012 4:29 pm
Subject: Re: the struggle for a 64-bit GCC on Solaris 10 - part 2
To: Ryan Johnson <ryan.johnson@cs.utoronto.ca>
Cc: Dennis Clarke <dclarke@blastwave.org>, Ian Lance Taylor <iant@google.com>, gcc-help@gcc.gnu.org, ebotcazou@adacore.com, jwakely.gcc@gmail.com


> On Mon, 12 Nov 2012, Ryan Johnson wrote:
> 
> > I'm still really unclear on why you're having so much trouble with 
> this. Have 
> > you tried bootstrapping with SunCC like I did?
> 
> I assume you mean suncc. gcc's code contains some C++ bugs that mean 
> that Oracle's C++ compiler won't compile it (a bit of an issue for 4.8).

I have these : 

$ /opt/solarisstudio12.3/bin/cc -V
cc: Sun C 5.12 SunOS_sparc 2011/11/16
$ /opt/solarisstudio12.3/bin/CC -V 
CC: Sun C++ 5.12 SunOS_sparc 2011/11/16

However I am not using that to bootstrap GCC. Also I am using /usr/ccs/bin/ld and
 /usr/ccs/bin/as and not GNU as or GNU ld. 

I am using : 

$ which gcc 
/opt/csw/gcc4/bin/gcc
$ gcc --version
gcc (Blastwave.org Inc. Mon Aug  9 07:10:45 GMT 2010) 4.5.1
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

See test report filed :

    http://gcc.gnu.org/ml/gcc-testresults/2010-08/msg01023.html


dc

Re: the struggle for a 64-bit GCC on Solaris 10 - part 2

[Ryan Johnson]

On 12/11/2012 4:32 PM, Dennis Clarke wrote:
>
> ----- Original Message -----
> From: Jonathan Wakely <jwakely.gcc@gmail.com>
> Date: Monday, November 12, 2012 4:26 pm
> Subject: Re: the struggle for a 64-bit GCC on Solaris 10 - part 2
> To: Dennis Clarke <dclarke@blastwave.org>
> Cc: Ryan Johnson <ryan.johnson@cs.utoronto.ca>, Ian Lance Taylor <iant@google.com>, gcc-help@gcc.gnu.org, ebotcazou@adacore.com
>
>
>> On 12 November 2012 21:20, Dennis Clarke wrote:
>>>> I'm still really unclear on why you're having so much trouble with
>>>> this.
>>>> Have you tried bootstrapping with SunCC like I did? Granted, I'm only
>>>> on
>>>> 5.9, but if newer versions fall down that's Oracle's fault, not gcc's.
>>> Since this is a purely gcc 4.7.2 bootstrapped with gcc 4.5.1 as the
>> compiler then it would be
>>> entirely in GCC land and not Oracle.
>> Except that the system headers which declare the problem function come
>> from Oracle.  And that doesn't answer the question.
> No .. I have gone digging to see what is going on in there but it is deep, wide and dark.
>
> I did file a bug report :
>
>      http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55293
>
> I hope I don't have to go fire up my old Solaris 8 server but, it did always result in a good looking GCC bootstrap.
You still didn't say why starting with the Solaris compiler is so 
undesirable... you do realize that the gcc you finally end up with 
(stage 3) will have been built by a gcc (stage 2) that was itself built 
by the gcc (stage 1) produced by suncc, right? Bootstrapping a separate 
version of gcc yourself just to build that stage 1 gcc with adds extra 
(and painful and unnecessary) steps to the process.

In the time you've spent writing these emails, a sunc-based bootstrap 
could have completed several times, modulo those funky CFLAGS you added. 
Heck, you could have bootstrapped 4.7.2 and then used *that* to 
bootstrap a "clean" 4.7.2 in the time these emails have taken so far.

Re: the struggle for a 64-bit GCC on Solaris 10 - part 2

[Dennis Clarke]

> > I hope I don't have to go fire up my old Solaris 8 server but, it 
> did always result in a good looking GCC bootstrap.

Let's clear the air here. 

> You still didn't say why starting with the Solaris compiler is so 
> undesirable... you do realize that the gcc you finally end up with 
> (stage 3) will have been built by a gcc (stage 2) that was itself 
> built  by the gcc (stage 1) produced by suncc, right? Bootstrapping a 
> separate version of gcc yourself just to build that stage 1 gcc with adds extra 

Okay, things I know as facts. 

fact : you can not build libgmp with Sun cc 

fact: I already have gcc compilers built and bootstrapped and tested and filed and then those in turn built other GCC compiler packages that have been tested and released and test reports filed. 

thought : I see no value in using the Sun/Oracle compilers to build GNU C compiler collection

> (and painful and unnecessary) steps to the process.

Also .. there are no Makefile changes done by me. I am working with a pure clean source code tarball from ft.gnu.org/pub/gnu/gcc with no mods from me at all. 

> In the time you've spent writing these emails, a sunc-based bootstrap 

I doubt that. Highly. 

> could have completed several times, modulo those funky CFLAGS you 
> added. 

No such funky CFLAGS are in effect. Only -m64 and a few non-funky totally sane falgs .. but hey .. I'll try it again without -D_TS_ERRNO and see what happens. 

> Heck, you could have bootstrapped 4.7.2 and then used *that* to 
> bootstrap a "clean" 4.7.2 in the time these emails have taken so far.

* sigh * 

Usually I do a triple bootstrap before I file a test report but thus far I have yet to see GCC 4.7.x bootstrap even once on Solaris 10.  Solaris 8 .. yeah sure, no problem. Solaris 10 .. no. 

So I will go back and do it again. 

Dennis 

Re: the struggle for a 64-bit GCC on Solaris 10 - part 2

[Jonathan Wakely]

On 12 November 2012 21:57, Dennis Clarke wrote:
>
> fact : you can not build libgmp with Sun cc

Doesn't matter.  It's a C library, you can compile it with GCC and
link it to code compiled with either GCC or Sun C.

> thought : I see no value in using the Sun/Oracle compilers to build GNU C compiler collection

Well if it works and the alternative doesn't ... maybe it's worth trying.

>> could have completed several times, modulo those funky CFLAGS you
>> added.
>
> No such funky CFLAGS are in effect. Only -m64 and a few non-funky totally sane falgs .. but hey .. I'll try it again without -D_TS_ERRNO and see what happens.

As I said on the bug report, you'll need to define _XOPEN_SOURCE or
_POSIX_C_SOURCE for the correct iconv(3) declaration.

Re: the struggle for a 64-bit GCC on Solaris 10 - part 2

[Dennis Clarke]

> On 12 November 2012 21:57, Dennis Clarke wrote:
> >
> > fact : you can not build libgmp with Sun cc
> 
> Doesn't matter.  It's a C library, you can compile it with GCC and
> link it to code compiled with either GCC or Sun C.
> 
> > thought : I see no value in using the Sun/Oracle compilers to build 
> GNU C compiler collection
> 
> Well if it works and the alternative doesn't ... maybe it's worth trying.
> 
> >> could have completed several times, modulo those funky CFLAGS you
> >> added.
> >
> > No such funky CFLAGS are in effect. Only -m64 and a few non-funky 
> totally sane falgs .. but hey .. I'll try it again without -D_TS_ERRNO 
> and see what happens.
> 
> As I said on the bug report, you'll need to define _XOPEN_SOURCE or
> _POSIX_C_SOURCE for the correct iconv(3) declaration.

I just tried that and the build fails in 70 seconds. 

So I am now trying something different. This is the exact same machine which ran for seven hours and 45 minutes and then failed on a code bug cause by some header wonkieness.  Nothing else has changed. So when I try a few defines like -D_POSIX_C_SOURCE=200112L -D_XOPEN_SOURCE=600 then I get this fail in 71 secs : 


gmake[3]: Entering directory `/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10/libiberty'
if [ x"-fPIC" != x ] && [ ! -d pic ]; then \
  mkdir pic; \
else true; fi
touch stamp-picdir
if [ x"-fPIC" != x ]; then \
  gcc -m64 -D_POSIX_C_SOURCE=200112L -D_XOPEN_SOURCE=600 -g -mno-app-regs -mcpu=v9 -D_TS_ERRNO -c -DHAVE_CONFIG_H -g -fkeep-inline-functions -I/usr/local/include:/opt/csw/gcc4/include -I. -I../../gcc-4.7.2/libiberty/../include  -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic  -fPIC ../../gcc-4.7.2/libiberty/regex.c -o pic/regex.o; \
else true; fi
In file included from /opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.5.1/include-fixed/sys/types.h:26:0,
                 from ../../gcc-4.7.2/libiberty/regex.c:51:
/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.5.1/include-fixed/sys/feature_tests.h:350:2: error: #error "Compiler or options invalid; UNIX 03 and POSIX.1-2001 applications     require the use of c99"
In file included from ../../gcc-4.7.2/libiberty/regex.c:51:0:
/opt/csw/gcc4/lib/gcc/sparc-sun-solaris2.8/4.5.1/include-fixed/sys/types.h:502:13: error: two or more data types in declaration specifiers
../../gcc-4.7.2/libiberty/regex.c:130:1: warning: function declaration isn't a prototype
../../gcc-4.7.2/libiberty/regex.c:130:7: warning: conflicting types for built-in function 'malloc'
../../gcc-4.7.2/libiberty/regex.c:131:1: warning: function declaration isn't a prototype
../../gcc-4.7.2/libiberty/regex.c:131:7: warning: conflicting types for built-in function 'realloc'
In file included from ../../gcc-4.7.2/libiberty/regex.c:638:0:
../../gcc-4.7.2/libiberty/regex.c: In function 'byte_regex_compile':
../../gcc-4.7.2/libiberty/regex.c:2439:7: warning: implicit declaration of function 'free'
../../gcc-4.7.2/libiberty/regex.c:2439:33: warning: incompatible implicit declaration of built-in function 'free'
../../gcc-4.7.2/libiberty/regex.c:2500:17: warning: incompatible implicit declaration of built-in function 'free'
../../gcc-4.7.2/libiberty/regex.c:2533:36: warning: incompatible implicit declaration of built-in function 'free'
../../gcc-4.7.2/libiberty/regex.c:2640:28: warning: incompatible implicit declaration of built-in function 'free'
../../gcc-4.7.2/libiberty/regex.c:3253:25: warning: implicit declaration of function 'strcmp'
../../gcc-4.7.2/libiberty/regex.c:3643:26: warning: incompatible implicit declaration of built-in function 'free'
../../gcc-4.7.2/libiberty/regex.c:4150:5: warning: incompatible implicit declaration of built-in function 'free'
../../gcc-4.7.2/libiberty/regex.c: In function 'byte_re_compile_fastmap':
../../gcc-4.7.2/libiberty/regex.c:4835:11: warning: implicit declaration of function 'abort'
../../gcc-4.7.2/libiberty/regex.c:4835:11: warning: incompatible implicit declaration of built-in function 'abort'
../../gcc-4.7.2/libiberty/regex.c: In function 'byte_re_match_2_internal':
../../gcc-4.7.2/libiberty/regex.c:7424:11: warning: incompatible implicit declaration of built-in function 'abort'
../../gcc-4.7.2/libiberty/regex.c: In function 'xre_comp':
../../gcc-4.7.2/libiberty/regex.c:7849:5: warning: implicit declaration of function 'strlen'
../../gcc-4.7.2/libiberty/regex.c:7849:34: warning: incompatible implicit declaration of built-in function 'strlen'
../../gcc-4.7.2/libiberty/regex.c: In function 'xre_exec':
../../gcc-4.7.2/libiberty/regex.c:7865:19: warning: incompatible implicit declaration of built-in function 'strlen'
../../gcc-4.7.2/libiberty/regex.c: In function 'xregcomp':
../../gcc-4.7.2/libiberty/regex.c:7964:40: warning: incompatible implicit declaration of built-in function 'strlen'
../../gcc-4.7.2/libiberty/regex.c:7978:4: warning: incompatible implicit declaration of built-in function 'free'
../../gcc-4.7.2/libiberty/regex.c: In function 'xregexec':
../../gcc-4.7.2/libiberty/regex.c:8011:13: warning: incompatible implicit declaration of built-in function 'strlen'
../../gcc-4.7.2/libiberty/regex.c:8053:7: warning: incompatible implicit declaration of built-in function 'free'
../../gcc-4.7.2/libiberty/regex.c: In function 'xregerror':
../../gcc-4.7.2/libiberty/regex.c:8081:5: warning: incompatible implicit declaration of built-in function 'abort'
../../gcc-4.7.2/libiberty/regex.c:8085:14: warning: incompatible implicit declaration of built-in function 'strlen'
../../gcc-4.7.2/libiberty/regex.c: In function 'xregfree':
../../gcc-4.7.2/libiberty/regex.c:8114:3: warning: incompatible implicit declaration of built-in function 'free'
gmake[3]: *** [regex.o] Error 1
gmake[3]: Leaving directory `/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10/libiberty'
gmake[2]: *** [all-stage1-libiberty] Error 2
gmake[2]: Leaving directory `/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10'
gmake[1]: *** [stage1-bubble] Error 2
gmake[1]: Leaving directory `/usr/local/build/gcc-4.7.2_sparc64-sun-solaris2.10'
gmake: *** [all] Error 2

real 71.45
user 17.65
sys 12.08
$ 

At least it was over quick. 

Am going to now try just -m64 -D_POSIX_C_SOURCE=200112L and nothing else. 

Really .. it shouldn't be this tough given that I have bootstrapped GCC a bizillion times before. 

dc

Re: the struggle for a 64-bit GCC on Solaris 10 - part 2

[Jonathan Wakely]

On 12 November 2012 22:22, Dennis Clarke wrote:
>
>
> Am going to now try just -m64 -D_POSIX_C_SOURCE=200112L and nothing else.

If you look at the headers giving the errors and you'll see that
you'll get the same result, so my suggestion to define those macros
doesn't help.

Re: the struggle for a 64-bit GCC on Solaris 10 - part 2

[Dennis Clarke]

----- Original Message -----
From: Jonathan Wakely <jwakely.gcc@gmail.com>
Date: Monday, November 12, 2012 5:32 pm
Subject: Re: the struggle for a 64-bit GCC on Solaris 10 - part 2
To: Dennis Clarke <dclarke@blastwave.org>
Cc: Ryan Johnson <ryan.johnson@cs.utoronto.ca>, Ian Lance Taylor <iant@google.com>, gcc-help@gcc.gnu.org, ebotcazou@adacore.com


> On 12 November 2012 22:22, Dennis Clarke wrote:
> >
> >
> > Am going to now try just -m64 -D_POSIX_C_SOURCE=200112L and nothing 
> else.
> 
> If you look at the headers giving the errors and you'll see that
> you'll get the same result, so my suggestion to define those macros
> doesn't help.

I'm giving this a try :

    CC='gcc -m64 -D__XOPEN_SOURCE=600 -g'

... thus far it has not blown up in 71 secs.  :-\

If this fails then I'll give up on Solaris 10 and roll back to Solaris 8 and create a SVR4 package there which I can install in Solaris 10. Other than running mkheaders, the package will run fine. Just a real drag to have to revert back to a ten year old OS to bootstrap.

dc 

Re: the struggle for a 64-bit GCC on Solaris 10 - part 2

[Jonathan Wakely]

On 12 November 2012 22:37, Dennis Clarke wrote:
>
> I'm giving this a try :
>
>     CC='gcc -m64 -D__XOPEN_SOURCE=600 -g'
>
> ... thus far it has not blown up in 71 secs.  :-\

It will fail with the same error in prettyprint.g

The macro __XOPEN_SOURCE is wrong, it should be a single underscore,
so the headers will ignore it and define the non-standard iconv(3)
signature, as it you hadn't defined the macro at all.

Re: the struggle for a 64-bit GCC on Solaris 10 - part 2

[Jonathan Wakely]

On 12 November 2012 22:49, Jonathan Wakely wrote:
> On 12 November 2012 22:37, Dennis Clarke wrote:
>>
>> I'm giving this a try :
>>
>>     CC='gcc -m64 -D__XOPEN_SOURCE=600 -g'
>>
>> ... thus far it has not blown up in 71 secs.  :-\
>
> It will fail with the same error in prettyprint.g

That should be pretty-print.c

Re: the struggle for a 64-bit GCC on Solaris 10 - part 2

[Dennis Clarke]

> On 12 November 2012 22:49, Jonathan Wakely wrote:
> > On 12 November 2012 22:37, Dennis Clarke wrote:
> >>
> >> I'm giving this a try :
> >>
> >>     CC='gcc -m64 -D__XOPEN_SOURCE=600 -g'
> >>
> >> ... thus far it has not blown up in 71 secs.  :-\
> >
> > It will fail with the same error in prettyprint.g
> 
> That should be pretty-print.c

I think at this point I am left wondering where the bug is. There must be a "bug" somewhere
because this process of just bootstrapping should work. It doesn't. I just don't see that filing
a bug report to Oracle would get me anywhere. 

Really, I'm trying to get a result here .. and not getting very far.  Maybe a change in 
pretty-print.c is needed .. not sure. 

I'll stop what I am doing and try again with -D_XOPEN_SOURCE=600 and then if it blows up 
in the usual 71 secs .. that's it. Give up on Solaris 10. 

Dennis 

Re: the struggle for a 64-bit GCC on Solaris 10 - part 2

[Dennis Clarke]

> On 12 November 2012 22:49, Jonathan Wakely wrote:
> > On 12 November 2012 22:37, Dennis Clarke wrote:
> >>
> >> I'm giving this a try :
> >>
> >>     CC='gcc -m64 -D__XOPEN_SOURCE=600 -g'
> >>
> >> ... thus far it has not blown up in 71 secs.  :-\
> >
> > It will fail with the same error in prettyprint.g
> 
> That should be pretty-print.c

Well .. one last try : 

$ 
$ date -u
Mon Nov 12 22:56:32 GMT 2012
$ 
$ CC='gcc -m64 -g -D_XOPEN_SOURCE=600' CXX='g++ -m64 -g -D_XOPEN_SOURCE=600' \
> ../gcc-4.7.2/configure --prefix=/usr/local/gcc4 --build=sparc64-sun-solaris2.10 --without-gnu-as \
> --without-gnu-ld --with-gmp=/usr/local --with-mpfr=/usr/local --with-mpc=/usr/local --with-ld=/usr/ccs/bin/ld \
> --enable-nls --enable-threads=posix --enable-shared --libdir=/usr/local/gcc4/lib --with-local-prefix=/usr/local/gcc4 \
> --with-cpu=v9 --enable-stage1-languages=c --disable-multilib --libexecdir=/usr/local/gcc4/lib \
> --with-pkgversion=Blastwave.org\ Inc.\ Mon\ Nov\ 12\ 22\:56\:32\ GMT\ 2012 \
> --with-bugurl=http\:\/\/www.blastwave.org\/support --enable-languages=c,c++,objc,fortran,ada --enable-bootstrap
checking build system type... sparc64-sun-solaris2.10
checking host system type... sparc64-sun-solaris2.10
checking target system type... sparc64-sun-solaris2.10
checking for a BSD-compatible install... ../gcc-4.7.2/install-sh -c
checking whether ln works... yes
checking whether ln -s works... yes
checking for a sed that does not truncate output... /usr/local/bin/gsed
checking for gawk... gawk
checking for libitm support... yes
checking for gcc... gcc -m64 -g -D_XOPEN_SOURCE=600
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... 
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc -m64 -g -D_XOPEN_SOURCE=600 accepts -g... yes
checking for gcc -m64 -g -D_XOPEN_SOURCE=600 option to accept ISO C89... unsupported
checking whether we are using the GNU C++ compiler... yes
checking whether g++ -m64 -g -D_XOPEN_SOURCE=600 accepts -g... yes
checking for gnatbind... gnatbind
checking for gnatmake... gnatmake
checking whether compiler driver understands Ada... yes
checking how to compare bootstrapped objects... cmp $$f1 $$f2 16 16
checking for objdir... .libs
checking for the correct version of gmp.h... yes
checking for the correct version of mpfr.h... yes
checking for the correct version of mpc.h... yes
checking for the correct version of the gmp/mpfr/mpc libraries... yes
checking for PWL_handle_timeout in -lpwl... no
checking for version 0.11 (revision 0 or later) of PPL... no
The following languages will be built: c,ada,c++,fortran,lto,objc
*** This configuration is not supported in the following subdirectories:
     target-libmudflap target-libgo target-libffi target-zlib target-libjava target-boehm-gc
    (Any other directories should still work fine.)
checking for default BUILD_CONFIG... bootstrap-debug
checking for bison... bison -y
checking for bison... bison
checking for gm4... /usr/local/bin/gm4
checking for flex... flex
checking for flex... flex
checking for makeinfo... makeinfo
checking for expect... expect
checking for runtest... runtest
checking for ar... (cached) /usr/ccs/bin/ar
checking for as... (cached) /usr/ccs/bin/as
checking for dlltool... no
checking for ld... (cached) /usr/ccs/bin/ld
checking for lipo... no
checking for nm... nm
checking for ranlib... ranlib
checking for strip... strip
checking for windres... no
checking for windmc... no
checking for objcopy... no
checking for objdump... no
checking for readelf... no
checking for cc... cc
checking for c++... c++
checking for gcc... gcc
checking for gcj... no
checking for gfortran... gfortran
checking for gccgo... no
checking for ar... no
checking for ar... ar
checking for as... no
checking for as... as
checking for dlltool... no
checking for dlltool... no
checking for ld... no
checking for ld... ld
checking for lipo... no
checking for lipo... no
checking for nm... no
checking for nm... nm
checking for objdump... no
checking for objdump... no
checking for ranlib... no
checking for ranlib... ranlib
checking for readelf... no
checking for readelf... no
checking for strip... no
checking for strip... strip
checking for windres... no
checking for windres... no
checking for windmc... no
checking for windmc... no
checking where to find the target ar... host tool
checking where to find the target as... host tool
checking where to find the target cc... just compiled
checking where to find the target c++... just compiled
checking where to find the target c++ for libstdc++... just compiled
checking where to find the target dlltool... host tool
checking where to find the target gcc... just compiled
checking where to find the target gcj... host tool
checking where to find the target gfortran... just compiled
checking where to find the target gccgo... host tool
checking where to find the target ld... host tool
checking where to find the target lipo... host tool
checking where to find the target nm... host tool
checking where to find the target objdump... host tool
checking where to find the target ranlib... host tool
checking where to find the target readelf... host tool
checking where to find the target strip... host tool
checking where to find the target windres... host tool
checking where to find the target windmc... host tool
checking whether to enable maintainer-specific portions of Makefiles... no
checking whether -fkeep-inline-functions is supported... yes
configure: creating ./config.status
config.status: creating Makefile
$ 

$ date -u 
Mon Nov 12 23:01:08 GMT 2012
$ 
$ banner last\ try

 #         ##     ####    #####           #####  #####    #   #
 #        #  #   #          #               #    #    #    # #
 #       #    #   ####      #               #    #    #     #
 #       ######       #     #               #    #####      #
 #       #    #  #    #     #               #    #   #      #
 ######  #    #   ####      #               #    #    #     #

I'll try to speed this up with gmake -j 8 : 

$ /usr/bin/time -p gmake -j 8 

... wish me luck

Dennis 

ps: I do wish to say thank you to members of the mail list. Otherwise I would have given up 
and simply said .. Solaris 10 can't bootstrap GCC.  Not bloody likely. :-)

Re: the struggle for a 64-bit GCC on Solaris 10 - part 2

[Ryan Johnson]

On 12/11/2012 5:13 PM, Jonathan Wakely wrote:
> On 12 November 2012 21:57, Dennis Clarke wrote:
>> fact : you can not build libgmp with Sun cc
> Doesn't matter.  It's a C library, you can compile it with GCC and
> link it to code compiled with either GCC or Sun C.
Well, that and I built it with Sun cc yesterday...

Re: the struggle for a 64-bit GCC on Solaris 10 - part 2

[Ryan Johnson]

On 12/11/2012 5:22 PM, Dennis Clarke wrote:
> So I am now trying something different. This is the exact same machine which ran for seven hours and 45 minutes
To bootstrap gcc on a two-socket Niagara II??? That's seriously messed 
up. The whole thing should take an hour, maybe 75 minutes, from 
unpacking gmp to invoking the newly-installed gcc. And that's on a 
single-socket version.

Re: the struggle for a 64-bit GCC on Solaris 10 - part 2

[Dennis Clarke]

> On 12/11/2012 5:13 PM, Jonathan Wakely wrote:
> > On 12 November 2012 21:57, Dennis Clarke wrote:
> >> fact : you can not build libgmp with Sun cc
> > Doesn't matter.  It's a C library, you can compile it with GCC and
> > link it to code compiled with either GCC or Sun C.
> Well, that and I built it with Sun cc yesterday...

You build gmp with what rev of Oracle Studio ? 

I was convinced, as are the authors of that lib, that it can't be done. 

dc

Re: the struggle for a 64-bit GCC on Solaris 10 - part 2

[Dennis Clarke]

> On 12/11/2012 5:22 PM, Dennis Clarke wrote:
> > So I am now trying something different. This is the exact same 
> machine which ran for seven hours and 45 minutes
> To bootstrap gcc on a two-socket Niagara II??? That's seriously messed 
> 
> up. The whole thing should take an hour, maybe 75 minutes, from 
> unpacking gmp to invoking the newly-installed gcc. And that's on a 
> single-socket version.

This is a resource capped non-global zone.  No one runs anything on my servers in
the gloabl zones. That would be ... evil. 

dc

Re: the struggle for a 64-bit GCC on Solaris 10 - part 2

[Ryan Johnson]

On 12/11/2012 6:17 PM, Dennis Clarke wrote:
>> On 12/11/2012 5:13 PM, Jonathan Wakely wrote:
>>> On 12 November 2012 21:57, Dennis Clarke wrote:
>>>> fact : you can not build libgmp with Sun cc
>>> Doesn't matter.  It's a C library, you can compile it with GCC and
>>> link it to code compiled with either GCC or Sun C.
>> Well, that and I built it with Sun cc yesterday...
> You build gmp with what rev of Oracle Studio ?
>
> I was convinced, as are the authors of that lib, that it can't be done.
$ cc -V
cc: Sun C 5.9 SunOS_sparc Patch 124867-11 2009/04/30
usage: cc [ options] files.  Use 'cc -flags' for details

I've used 5.10 as well, on a different machine.

Like I said before, if later versions are broken, that's Oracle's fault, 
not gcc's.

Ryan

Re: the struggle for a 64-bit GCC on Solaris 10 - part 2

[Jonathan Wakely]

On 12 November 2012 22:55, Dennis Clarke wrote:
>
> I think at this point I am left wondering where the bug is. There must be a "bug" somewhere
> because this process of just bootstrapping should work. It doesn't. I just don't see that filing
> a bug report to Oracle would get me anywhere.
>
> Really, I'm trying to get a result here .. and not getting very far.  Maybe a change in
> pretty-print.c is needed .. not sure.
>
> I'll stop what I am doing and try again with -D_XOPEN_SOURCE=600 and then if it blows up
> in the usual 71 secs .. that's it. Give up on Solaris 10.

I've just successfully bootstrapped x86_64-pc-solaris2.10 using GCC
4.4.3 as the bootstrap compiler, with in-tree gmp/mpfr/mpc, without
setting any CFLAGS at all, just

CC='gcc -m64' CXX='g++ -m64' ../gcc-4.7.2/configure
--build=x86_64-pc-solaris2.10

I had no problems with the iconv() definition in pretty-print.c, my
builddir/gcc/config.log shows it wasn't found:

| /* end confdefs.h.  */
| #include <stdlib.h>
| #include <iconv.h>
| int
| main ()
| {
| iconv_t cd = iconv_open("","");
|        iconv(cd,NULL,NULL,NULL,NULL);
|        iconv_close(cd);
|   ;
|   return 0;
| }
configure:10309: gcc -m64 -o conftest -g -fkeep-inline-functions
-I/usr/local/include   conftest.c  /usr/local/lib/libiconv.so
-L/usr/local/lib -L/usr/openwin/lib -L/usr/local/ssl/lib
-L/usr/local/BerkeleyDB.4.2/lib -R/usr/local/lib >&5
ld: fatal: file /usr/local/lib/libiconv.so: wrong ELF class: ELFCLASS32

Which means the code failing for you in pretty-print.c isn't compiled,
because of:

#if defined ENABLE_NLS && defined HAVE_LANGINFO_CODESET && HAVE_ICONV

On your system presumably builddir/gcc/config.log shows iconv() is
found, and so configure defines HAVE_ICONV.

What does 'grep builddir/gcc/config.log'  show?

What does 'env | grep PATH' show?  Do you have something in your
LD_LIBRARY_PATH which causes the failing test above to pass?

I think the bug is that the configure test for iconv only tests:
        iconv(cd,NULL,NULL,NULL,NULL);
which doesn't check for a POSIX-conforming signature.

Re: the struggle for a 64-bit GCC on Solaris 10 - part 2

[Dennis Clarke]

> I've just successfully bootstrapped x86_64-pc-solaris2.10 using GCC
> 4.4.3 as the bootstrap compiler, with in-tree gmp/mpfr/mpc, without
> setting any CFLAGS at all, just

the following works on Solaris 10 Sparc : 

$ CC='gcc -m64' CXX='g++ -m64'  ../gcc-4.7.2/configure \
--build=sparc64-sun-solaris2.10 --prefix=/usr/local/gcc4 \
--with-gmp=/usr/local --with-mpfr=/usr/local --with-mpc=/usr/local \
--disable-nls --enable-threads=posix --enable-shared \
--libdir=/usr/local/gcc4/lib --with-local-prefix=/usr/local/gcc4 \
--disable-multilib --enable-languages=c,c++,objc,fortran,ada \
--enable-bootstrap

I have to run a testsuite on this to see what I have but at least the bootstrap was clean looking. 

Oh, also, after install : 

dclarke@unreal $ find /usr/local/gcc4/ -type f | xargs file | grep ELF | cut -f2 -d\: | sort -u 
 ELF 64-bit MSB dynamic lib SPARCV9 Version 1, dynamically linked, not stripped
 ELF 64-bit MSB executable SPARCV9 Version 1, dynamically linked, not stripped
 ELF 64-bit MSB relocatable SPARCV9 Version 1

Not a 32-bit object to be seen.  Perfect. 

Dennis