N64A enable-static-engine
> ms\do_win64a
> nmake -f 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 supp
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
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 withou
nd reaction to reports can 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,
orts can 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 advant
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 i
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 with
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 /Fotmp32\x86_6
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.or
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 openssl-dev@opens
> 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 tmp32dll\x
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
tmp32d
>> With Visual Studio 10 x64, I get the following error at configure time:
>>
>> ...
>> D:\build.ntx64vs10>perl ms\uplink-x86_64.pl masm 1>ms\uptable.asm
>> D:\build.ntx64vs10>ml64 -c -Foms\uptable.obj ms\uptable.asm
>> Assembli
>> With Visual Studio 10 x64, I get the following error at configure time:
>>
>> ...
>> D:\build.ntx64vs10>perl ms\uplink-x86_64.pl masm 1>ms\uptable.asm
>> D:\build.ntx64vs10>ml64 -c -Foms\uptable.obj ms\uptable.asm
>> Assembli
> With Visual Studio 10 x64, I get the following error at configure time:
>
> ...
> D:\build.ntx64vs10>perl ms\uplink-x86_64.pl masm 1>ms\uptable.asm
> D:\build.ntx64vs10>ml64 -c -Foms\uptable.obj ms\uptable.asm
>Assembling: ms\uptable.asm
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.ntx64vs10>perl ms\uplink-x86_64.pl masm 1>ms\uptable.asm
D:\build.ntx64vs10>ml64 -c -Foms\
> The latest snapshot that has this checkin, has a Perl syntax error on line
> 573
> of crypto/perlasm/x86_64-xlate.pl (missing ; on the line above)
>
> Using perl 5.8.4 on Solaris 10.
Ooops. Fixed. Thanks.
__
OpenSSL Project
cation on Win64 x64 when built with default (masm) compilation...
>From: "Andy Polyakov via RT"
>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
T [mailto:r...@openssl.org]
> 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, 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 h
Andy Polyakov via RT [mailto:r...@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...
>
>
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 an
> 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
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
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 '
> [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-u
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 with
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
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.
>
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 g
31 matches
Mail list logo
