> FYI:
>
> ar -V
> GNU ar version 2.5.2
Too old, but I don't beleive it causes the problem... But who knows...
To be honest I never ran GNU binutils under Solaris as there is really
*no* reason for doing so. I just compare your versioin numbers with to
what they have in RedHat 6.0 for UltraSPARC where corresponding
linux-sparcv9 option is known to work properly.
>
> nm -V
> GNU nm version 2.5.2
Redhat says 2.9.1
>
> as -V
> GNU assembler version 2.2 (sparc-sun-solaris2.3), using BFD version 2.2
Redhat says 2.9.1, using BFD 2.9.1.0.23
>
> ld -V
> ld: Software Generation Utilities - Solaris/ELF (3.0)
>
> /usr/local/GNU/bin/ld -V
> ld version 2.5.2 (with BFD 2.5)
Readhat says 2.9.1 with BFD 2.9.1.0.23.
>
> Andy> Ulf wrote:
>
> >> So, "sun4u" (and even "Ultra-2" in the uname output) does not imply
> >> that we can use -multrasparc?
>
> I successfully build the system with :
>
> solaris-sparcv8-gcc
>
> as opposed to the default setting for "sun4u*-sun-solaris2"
>
> solaris-sparcv9-gcc
If you would keep your binutils up-to-date this one would work just fine
as well and you would be able to accept more connections per unit of
time (thanks to specially optimized for UltraSPARC bignum routines).
>
> Andy> I bet it does and the problem is very likely caused by out-of-date
> Andy> GNU binutils present on the $PATH and/or in /.../gcc-lib/../*.
>
> Surely version test of the utilities at Configure would resolve some of this.
In ./LICENSE it says:
* THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY
* EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
* PURPOSE ARE DISCLAIMED.
It's not feasible to check for presence and maintain every possible
combination of (out-dated) tools. The library was developed in
"bare-boned" configuration (no alien binutils present).
>
> >> What do we have to test for to get it right?
> Andy> We could demand having /usr/ccs/bin *first* in the
> Andy> $PATH. Unfortunately it won't help in situations when people have
> Andy> out-of-date GNU binutils ('as' and 'ld' in particular) fused into
> Andy> the path they have feeded the the gcc configure script with through
> Andy> the --prefix option. As it was already discussed here gcc looks for
> Andy> components like 'as' and 'ld' in its --prefix tree first and only
> Andy> then falls down to vendor provided utilities:-( Just run 'truss -f
> Andy> -t exec,access gcc a.c' to see where does it look for the stuff...
>
> It could well be because I have my system configured to make use of the
> System "ld" as opposed to the GNU "ld". This being historical due to various
> warnings of using the GNU "ld" on Sparc Solaris system.
As I already said in order to be sure wich ld does gcc invoke run 'gcc
-v a.c' and/or 'truss -f -t exec,access gcc a.c', not just 'ld -V' and
pick up whatever found on the $PATH first.
Cheers. Andy.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
