> > What isn't clear is where that is run. I decided that I will take your
> > approach and try to follow the magic incantations to the very
> letter. OKay,
> > sort of. I may expand on the CFLAGS just a little bit and I have to
> assume,
> > in the absence of any data, that I shall run these "config ; make; make
> > check" incantations inside the GCC build dir.
>
> Well, of course not, you must build them as usual.
I sort of figured that .. however there was this little voice in my head that
said "you know .. you have been doing this a long long time and you never had
these problems so let's just do it his way" and so I did.
> > $ CC='gcc -mno-app-regs -mcpu=v9 -m64 -mptr64 -g -D_POSIX_PTHREAD_SEMANTICS
> > -D_LARGEFILE64_SOURCE -D_TS_ERRNO' \
> > > CXX='g++ -mno-app-regs -mcpu=v9 -m64 -mptr64 -g
> > > -D_POSIX_PTHREAD_SEMANTICS -D_LARGEFILE64_SOURCE -D_TS_ERRNO' \
> > > ../gmp-5.0.5_SunOS5.10_sparcv9-for-gcc-4.7.2/configure ABI=64
> > > --enable-cxx --prefix=/usr/local/gcc4 \ --libdir=/usr/local/gcc4/lib
> > > --build=sparc64-sun-solaris2.10
>
> Totally puzzled here.... why on Earth are you using all these flags?
> Just use the configure lines posted by Ryan.
Well in Solaris we need a define _TS_ERRNO in order to get a thread safe errno.
Otherwise it can not be relied upone. The other two defines are sort of self
explanatory. I felt that the sparc v9 would ensure that whatever binary object
gets produced will run on any UltraSparc chip in the past ten years. The -g was
simply to ensure that I could possible use a debugger in the future if ever
needed and the -mptr64 I forgot.
The -mno-app-regs is pretty imporant for shared libs. I do need the shared
libs. From the gcc docs :
To be fully SVR4 ABI-compliant at the cost of some performance loss,
specify -mno-app-regs. You should compile libraries and system software
with this option.
So even when I use the Oracle Studio compilers I ensure that I have
-xregs=no%appl to protect global registers 2 through 4.
Those were my thoughts there and the build was flawless.
> > The result however, is that the gcc build dir is polluted with
> > objects from the gmp build.
> >
> > Not what I want most likely.
>
> Then do not build them in the GCC build dir!
uh yeah .. that was just plain stupid of me. :-)
