Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

gcc 4.4.2 build on Solaris 10 64bit

322 views
Skip to first unread message

Paul Dietrich

unread,
Oct 18, 2009, 6:05:48 AM10/18/09
to
Finally,
I have a build, but it seems like it could be better. Here is how the
build went:
System is an Ultra 60 with one processor and 768 MB RAM
cat /etc/release
Solaris 10 5/09 s10s_u7wos_08 SPARC
Copyright 2009 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
Assembled 30 March 2009

Created 64 bit libs for following with /usr/sfw/bin/gcc shipped compiler:
Added gmp v4.3.1
Added mpfr v2.4.1
Used /usr/bin/bash shell

crle -64 -c /var/ld/64/ld.config -l
/lib/64:/usr/lib/64:/opt/ssl/lib:/usr/sfw/lib/sparcv9:/usr/local/lib

CC=/usr/sfw/bin/gcc
CFLAGS="-m64 -mcpu=ultrasparc -pthreads -O3"
CPPFLAGS="-I/usr/sfw/include -I/usr/local/include"
CXX=/usr/sfw/bin/g++
CXXFLAGS=-m64 -mcpu=ultrasparc -pthreads -O3
LDFLAGS="-64 -s -L/usr/sfw/lib/sparcv9 -L/usr/local/lib"
MAKE=/usr/sfw/bin/gmake
PATH=/usr/sfw/bin/sparcv9:/usr/ccs/bin/sparcv9:/usr/sfw/bin:/usr/sbin:/usr/bin:/
usr/ccs/bin:/usr/perl5/bin
SHELL=/usr/bin/bash
export CC CFLAGS CPPFLAGS CXX CXXFLAGS LDFLAGS MAKE PATH SHELL

gtar -xvf gcc-4.4.2.tar
mkdir gcc-objdir
cd gcc-objdir
../gcc-4.4.2/configure --build=sparc64-sun-solaris2.10 --with-as=/usr/ccs/bin/as
--without-gnu-as --disable-multilib --enable-shared --enable-languages=c,c++
--disable-bootstrap

gmake
gmake install


Would like to use bootstrap, profiling, build f77, build both 32 and 64 bit
libs, but didn't figure it out.
Anybody else building and want to suggest anything?


Paul Floyd

unread,
Oct 18, 2009, 8:32:18 AM10/18/09
to
On Sun, 18 Oct 2009 03:05:48 -0700, Paul Dietrich <dufu...@yahoo.com> wrote:
> Finally,
> I have a build, but it seems like it could be better. Here is how the
> build went:
> System is an Ultra 60 with one processor and 768 MB RAM

Even on SPARC terms, that's going to be a slow machine.

> cat /etc/release
> Solaris 10 5/09 s10s_u7wos_08 SPARC
> Copyright 2009 Sun Microsystems, Inc. All Rights Reserved.
> Use is subject to license terms.
> Assembled 30 March 2009

Probably not relevant, but Solaris 10 10/09 was recently released.

> Created 64 bit libs for following with /usr/sfw/bin/gcc shipped compiler:
> Added gmp v4.3.1
> Added mpfr v2.4.1
> Used /usr/bin/bash shell
>
> crle -64 -c /var/ld/64/ld.config -l
> /lib/64:/usr/lib/64:/opt/ssl/lib:/usr/sfw/lib/sparcv9:/usr/local/lib

Do you have only 64bit libs in /usr/local/lib? This seems dangerous to
me. Can't you put 64bit libs in /usr/local/lib/sparcv9 and 32bit libs in
/usr/local/lib?

[snip]

> Would like to use bootstrap, profiling, build f77, build both 32 and 64 bit
> libs, but didn't figure it out.
> Anybody else building and want to suggest anything?

Use Sun Studio, unless the source that you wish to compile is of poor
quality and wedded to GCC by the use of non-standard extensions.

A bientot
Paul
--
Paul Floyd http://paulf.free.fr

Paul Dietrich

unread,
Oct 29, 2009, 12:05:58 AM10/29/09
to

"Paul Floyd" <ro...@127.0.0.1> wrote in message
news:slrnhdm2p...@tryfan.orange.fr...

> On Sun, 18 Oct 2009 03:05:48 -0700, Paul Dietrich <dufu...@yahoo.com>
> wrote:
>> Finally,
>> I have a build, but it seems like it could be better. Here is how
>> the
>> build went:
>> System is an Ultra 60 with one processor and 768 MB RAM
>
> Even on SPARC terms, that's going to be a slow machine.
>
sure, a bit slow, but is the only sparc I have in the house
beats about 50% of the 35 systems I have. If I can compile here, I can
compile on most later sparcs and just change the mcpu parameter

>> cat /etc/release
>> Solaris 10 5/09 s10s_u7wos_08 SPARC
>> Copyright 2009 Sun Microsystems, Inc. All Rights Reserved.
>> Use is subject to license terms.
>> Assembled 30 March 2009
>
> Probably not relevant, but Solaris 10 10/09 was recently released.
>

Yes, but wouldn't be that much diff since I've applied a recommended patch
bundle. I'll probably upgrade my solaris boxes in december. My usual 60
day waiting period.

>> Created 64 bit libs for following with /usr/sfw/bin/gcc shipped compiler:
>> Added gmp v4.3.1
>> Added mpfr v2.4.1
>> Used /usr/bin/bash shell
>>
>> crle -64 -c /var/ld/64/ld.config -l
>> /lib/64:/usr/lib/64:/opt/ssl/lib:/usr/sfw/lib/sparcv9:/usr/local/lib
>
> Do you have only 64bit libs in /usr/local/lib? This seems dangerous to
> me. Can't you put 64bit libs in /usr/local/lib/sparcv9 and 32bit libs in
> /usr/local/lib?
>
> [snip]
>

Yea, only 64 bit libs currently, by using default locations for gmp and
mpfr. I concur, would be a good idea to seperate.

>> Would like to use bootstrap, profiling, build f77, build both 32 and 64
>> bit
>> libs, but didn't figure it out.
>> Anybody else building and want to suggest anything?
>
> Use Sun Studio, unless the source that you wish to compile is of poor
> quality and wedded to GCC by the use of non-standard extensions.
>
> A bientot
> Paul
> --
> Paul Floyd http://paulf.free.fr

The Sun Studio can handle the gcc compiler, but I thought I would learn more
by avoiding the setup and config issues of an IDE while I get this working.
My plan is to compile other software with Sun Studio 12 and gcc 4.4.2.

Thanks for the tips. Hope I can get some feedback on bootstrap. Seems like
the way to go from what I read on the gnu gcc site.


Paul Floyd

unread,
Oct 30, 2009, 5:52:55 PM10/30/09
to
On Wed, 28 Oct 2009 21:05:58 -0700, Paul Dietrich <dufu...@yahoo.com> wrote:
>>
>> Even on SPARC terms, that's going to be a slow machine.
>>
> sure, a bit slow, but is the only sparc I have in the house
> beats about 50% of the 35 systems I have. If I can compile here, I can
> compile on most later sparcs and just change the mcpu parameter

If you have ~17 machines slower than an ultra 60, that's not a house
you've got, it's a museum!

> The Sun Studio can handle the gcc compiler, but I thought I would learn more
> by avoiding the setup and config issues of an IDE while I get this working.
> My plan is to compile other software with Sun Studio 12 and gcc 4.4.2.

You don't have to use the IDE. Personally I tend to prefer to have a
second (or more) compiler opinion on my code. It tends to result in
avoiding compiler idiosyncracies. And crank up the warning level (like
-ansi -pedantic -Wextra -Wall).

0 new messages