Andy Polyakov wrote:
There are trivial differences between Solaris 2.5.1 and the later
Solaris versions. Not enough to cause a build problem. So if
it's busted on 2.5.1 it will be busted on 2.6, 2.7 etc.
Newer Solaris version *are* equipped with newer assembler, which *does*
support more x86 instructions, such as those used in wp-mmx module.
OK.
Plus, that
illegal mnemonic error has happened before and been corrected
before in openssl.
You must be referring to "illegal mnemonic" mentioned in Configure in
"Solaris x86 with GNU C setups" section. For completeness sake it should
be noted that newer GNU C versions (or one(s) provided by Sun?) do not
exhibit this behavior and it's perfectly possible to compile without
NO_INLINE_ASM.
However, the newer gcc took out the hack to make assembler work with
Sun's linker
so there's another hack you have to do to get it to compile with gcc
3.x (it's documented
in the FAQ for openssl I recall)
In other words, failure to compile on Solaris 2.5.1 and gcc 2.95.3 does
not necessarily mean that it shall fail to compile on later versions. I
mean the opening statement does not hold true:-)
OK, point taken. Obsolescense, then.
Finally, compilation with "no-asm" means NO
ASSEMBLY, NONE, NADA!!! While you might be able to argue
obsolescense on the first compile, the second compile with no-asm
defined shouldn't have errored.
Correct, it shouldn't have failed. In other words this is bug.
http://cvs.openssl.org/chngview?cn=17985 is the cure.
Thanks! I'll try out tomorrow's snap and let you all know.
Obviously, whoever coded wp-mmx
wasn't paying attention to -DOPENSSL_NO_INLINE_ASM. Not to mention
the larger question of why wp-mmx was even selected - not all Intel
chips HAVE mmx instructions.
What does pure assembler wp-mmx have to do with NO_INLINE_ASM? In either
case, MMX capability is detected at run-time and whirlpool_block_mmx is
*not* invoked on CPU not capable to execute it. This naturally implies
that there *is* equivalent non-mmx code. This applies to all
MMX/SSE/SSE2 modules. This is totally intentional, i.e. this is not a
bug. One can argue that there should be a way to selectively disable
"strange" modules [for impaired assemblers' sake], but where would one
draw the line? This is more of rhetorical question, because as long as
no-asm does the trick, the line is drawn right there.
That does it for me - no-asm is just fine. Nobody would seriously use
an obsolete
platform to do a lot of intense crypto on, so the slower speed that
no-asm introduces
is not a problem. But lots of people would like to continue to update
the ssh
daemon on their obsolete platforms.
If you're not
satisfied with this all-or-nothing option, feel free to remove
wp_block.o wp-mmx.o from $x86_asm in Configure.
I might try that just to see what happens.
Thanks!
Ted
Or install GNU binutils
(so that you get more up-to-date assembler) and reconfigure compiler to
use GNU assembler and not Solaris one... A.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
