ms\ntdll.mak
In both cases the makefile uses MASM to compile the assembly. The
INSTALL.W32 seems to contradict that though because it says NASM is the
only supported assembler.
Where is contradiction? It says the only supported, not the only
working. But don't get this as masm is supposed
In both cases the makefile uses MASM to compile the assembly. The
INSTALL.W32 seems to contradict that though because it says NASM is the
only supported assembler. And in the case of x86 do_ms passes arg
'no-asm' to mk1mf.pl but that doesn't seem to do anything, and I'm not
sure if that's
Lots of things got in the way since March, but I've had a chance to re-look
at this issue. I had gotten as far as creating some patches but had not
fully vetted them -- just this week I tried again and found that for the
9/10 snapshot generates with VS 2013 Express Edition MASM 64 bit without
any
as
well be avoiding problem.
As for supporting MASM in more general terms. You have to do better than
it's *nice* to have MASM. You have to show why is it so, what is it
MASM offers that NASM doesn't. Even if there are some/any, they would be
weighed against advantages NASM has to offer
as
well be avoiding problem.
Well then I will definitely send in my more complete analysis/proposed
fixes.
As for supporting MASM in more general terms. You have to do better than
it's *nice* to have MASM. You have to show why is it so, what is it
MASM offers that NASM doesn't. Even if there are some
using Visual Studio Express
edition. The new Visual Studios include ml/ml64, and while NASM is
great sometimes it is nice to have the option of MASM as well.
I was trying to do things with the built-in translator and other
support code but decided to get the biggest initial return on invested
I wanted to be able to build 32 and 64 bit versions of recent OpenSSL
1.0.x production and beta/snapshots using Visual Studio Express
edition. The new Visual Studios include ml/ml64, and while NASM is
great sometimes it is nice to have the option of MASM as well.
I was trying to do things
Mike Inman via RT wrote:
crypto/bn/asm/x86_64-gf2m.pl was not finishing code generation before the
assembler started, resulting in errors that looked like:
set ASM=ml64 /c /Cp /Cx /Zi
perl crypto\bn\asm\x86_64-gf2m.pl tmp32\x86_64-gf2m.asm
ml64 /c /Cp /Cx /Zi
crypto/bn/asm/x86_64-gf2m.pl was not finishing code generation before the
assembler started, resulting in errors that looked like:
set ASM=ml64 /c /Cp /Cx /Zi
perl crypto\bn\asm\x86_64-gf2m.pl tmp32\x86_64-gf2m.asm
ml64 /c /Cp /Cx /Zi /Fotmp32\x86_64-gf2m.obj tmp32\x86_64-gf2m.asm
The commit has a typo, the second line should read *STDOUT=*OUT;.
The fix works, thanks!
Yes, it was fixed few minutes after. Dismissing the case.
__
OpenSSL Project http://www.openssl.org
The commit has a typo, the second line should read *STDOUT=*OUT;.
The fix works, thanks!
__
OpenSSL Project http://www.openssl.org
Development Mailing List
When building OpenSSL 1.0.1e in the context of a larger build, the build fails
with the following error:
perl crypto\bn\asm\x86_64-gf2m.pl tmp32dll\x86_64-gf2m.asm
ml64 /c /Cp /Cx /Zi /Fotmp32dll\x86_64-gf2m.obj tmp32dll\x86_64-gf2m.asm
Assembling: tmp32dll\x86_64-gf2m.asm
When building OpenSSL 1.0.1e in the context of a larger build, the build
fails with the following error:
See http://rt.openssl.org/Ticket/Display.html?id=2963. Note that there
were multiple suggestions, but 1st reportedly did the trick.
perl crypto\bn\asm\x86_64-gf2m.pl
With Visual Studio 10 x64, I get the following error at configure time:
...
D:\build.ntx64vs10perl ms\uplink-x86_64.pl masm 1ms\uptable.asm
D:\build.ntx64vs10ml64 -c -Foms\uptable.obj ms\uptable.asm
Assembling: ms\uptable.asm
ms\uptable.asm(356) : error A2088
With Visual Studio 10 x64, I get the following error at configure time:
...
D:\build.ntx64vs10perl ms\uplink-x86_64.pl masm 1ms\uptable.asm
D:\build.ntx64vs10ml64 -c -Foms\uptable.obj ms\uptable.asm
Assembling: ms\uptable.asm
ms\uptable.asm(356) : error A2088
I don't have any problem compiling OpenSSL in 32-bit mode with either
compiler.
With Visual Studio 10 x64, I get the following error at configure time:
...
D:\build.ntx64vs10perl ms\uplink-x86_64.pl masm 1ms\uptable.asm
D:\build.ntx64vs10ml64 -c -Foms\uptable.obj ms
With Visual Studio 10 x64, I get the following error at configure time:
...
D:\build.ntx64vs10perl ms\uplink-x86_64.pl masm 1ms\uptable.asm
D:\build.ntx64vs10ml64 -c -Foms\uptable.obj ms\uptable.asm
Assembling: ms\uptable.asm
ms\uptable.asm(356) : error
x64 when built with default (masm) compilation...
From: Andy Polyakov via RT r...@openssl.org
To: d...@ziggurat29.com
Cc: openssl-dev@openssl.org
Date: Sat, 21 Jan 2012 12:41:03 +0100 (CET)
Reply-To: openssl-dev@openssl.org
Looks like it is still there in 1.0.0g
Right, modification made
]
Sent: Saturday, January 21, 2012 5:41 AM
To: d...@ziggurat29.com
Cc: openssl-dev@openssl.org
Subject: Re: [openssl.org #2620] Resolved: static libs cause
crash in linking application on Win64 x64 when built with
default (masm) compilation...
Looks like it is still there in 1.0.0g
Right
Looks like it is still there in 1.0.0g
Right, modification made to 1.0.1 as focus was on beta...
Again, it's an alignment issue of function pointers put into an array
processed by the C-runtime normally used for doing things like global
constructors.
I actually have hard time imagining how
...@openssl.org]
Sent: Sunday, January 15, 2012 8:00 AM
To: d...@ziggurat29.com
Subject: [openssl.org #2620] Resolved: static libs cause
crash in linking application on Win64 x64 when built with
default (masm) compilation...
According to our records, your request has been resolved. If
you
configuration:
* openssl 1.0.0.e
* Win64, DS2010 toolchain
* static library
* default (using asm modules) configuration
When built in above configuration, a linking application will crash in
c-runtime startup code (i.e. before reaching main()).
This is due to some linker magic which causes
Adding a conditional declaration for XMMWORD allows either MASM 6, MASM 7, or
MASM 8 to assemble
OpenSSL 0.9.8g correctly, including the SSE2 instructions in sha512-sse2.asm:
IF @Version LT 800
XMMWORD STRUCT 16
DQ 2 dup (?)
XMMWORD ENDS
ENDIF
Fixed per http://cvs.openssl.org
Adding a conditional declaration for XMMWORD allows either MASM 6, MASM 7, or
MASM 8 to assemble
OpenSSL 0.9.8g correctly, including the SSE2 instructions in sha512-sse2.asm:
IF @Version LT 800
XMMWORD STRUCT 16
DQ 2 dup (?)
XMMWORD ENDS
ENDIF
x86ms.pl could do this:
--- crypto
Starting with OpenSSL 0.9.8f, Windows builds using ms\do_masm.bat generate .asm
files with the MASM
directive XMMWORD.
XMMWORD was added to MASM 8 (Visual Studio C++ 2005).
ref: http://msdn2.microsoft.com/en-us/library/cw0399sf(VS.80).aspx
This prevents building OpenSSL via ms\do_masm.bat
[EMAIL PROTECTED] - Thu Oct 18 09:05:32 2007]:
Starting with OpenSSL 0.9.8f, Windows builds using ms\do_masm.bat
generate .asm files with the MASM
directive XMMWORD.
XMMWORD was added to MASM 8 (Visual Studio C++ 2005).
ref: http://msdn2.microsoft.com/en-us/library/cw0399sf(VS.80).aspx
MASM 6.15+ includes support for the SSE2 instructions, like movdqa, movdqu, etc.
It is only the XMMWORD directive that forces the use of the Visual Studio 2005
assembler.
If QWORD is substituted for XMMWORD, MASM 6 can assemble the .asm sources.
Testing OpenSSL built with MASM 6 and this 'QWORD
Hi!
When trying to make a debug win32 link with a MASM 6.11-generated
s1-win32.obj I get the following warning:
libeay32.lib(s1-win32.obj) : warning LNK4200: corrupt line number
information in object file; ignored
NASM-0.98 apperars to have no problems though.
Cheers,
//oscar
S/MIME
As I mentioned earlier, MASM is available in the DDK. What I hadn't
realised, but have been told by a kind informant, is that the DDK is
free.
http://www.microsoft.com/ddk/ddk40.htm
So, MASM really should not be a problem.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandf
Ben Laurie wrote:
As I mentioned earlier, MASM is available in the DDK. What I hadn't
realised, but have been told by a kind informant, is that the DDK is
free.
http://www.microsoft.com/ddk/ddk40.htm
So, MASM really should not be a problem.
Erk. Thats weird. I've read a page
30 matches
Mail list logo
