Build error with 1.0.1e on Win64 with VC++ 2010 and nasm

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Build error with 1.0.1e on Win64 with VC++ 2010 and nasm

Phillip Hellewell-2
I'm trying to upgrade from 0.9.8y to 1.0.1e, but I'm getting this linker error.

 link /nologo /subsystem:console /opt:ref /debug /dll
/out:out32dll\libeay32.dll /def:ms/LIBEAY32.def
@C:\Users\PHELLE~1\AppData\Local\Temp\nm6C7E.tmp
   Creating library out32dll\libeay32.lib and object out32dll\libeay32.exp
bn_gf2m.obj : error LNK2019: unresolved external symbol
bn_GF2m_mul_2x2 referenced in function BN_GF2m_mod_mul_arr
out32dll\libeay32.dll : fatal error LNK1120: 1 unresolved externals
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual
Studio 10.0\VC\BIN\amd64\link.EXE"' : return code '0x460'

A helpful post on stackoverflow led me to find that if I build with
"no-asm", it will work, and it does.

But do I have to sacrifice performance to be able to upgrade to 1.0.1?

Phillip
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Build error with 1.0.1e on Win64 with VC++ 2010 and nasm

Phillip Hellewell-2
On Thu, May 16, 2013 at 5:27 PM, Phillip Hellewell <[hidden email]> wrote:
> But do I have to sacrifice performance to be able to upgrade to 1.0.1?

Anyone?  Can I be the only one in the whole world who wants to build
openssl on Windows 64-bit with optimized assembly routines?

Should I try to patch it myself?  Should I be posting this to
openssl-dev instead?

Phillip
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Build error with 1.0.1e on Win64 with VC++ 2010 and nasm

Phillip Hellewell-2
On Mon, May 20, 2013 at 1:12 PM, Phillip Hellewell <[hidden email]> wrote:
> Should I try to patch it myself?

FYI, the linker error is occurring because nasm is failing with a ton
of errors on x86_64-g2m.asm, I think maybe because it is creating the
wrong type of asm.

So I tried masm instead, and it is working sometimes, but sometimes I get this:
tmp32dll\x86_64-gf2m.asm(1) : error A2088:END directive required at end of file

Assuming I can get past that, the conclusion is that I have to use
masm for 64-bit and nasm for 32-bit.  And since do_win64a.bat and
other spots are set up to just use nasm automatically when available,
I have to play a silly game in my build script where I hide nasm.exe
from my path while building 64-bit, then put it back in my path while
building 32-bit.

Phillip
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Build error with 1.0.1e on Win64 with VC++ 2010 and nasm

J. J. Farrell-2
It might be better if you specify how you set up your environment, what versions of perl and nasm you used, and what sequence of commands you used.

I usually do a cut-down static build in an environment based on the Windows Driver Kit, and I've built 1.0.1e using nasm without problems. I just tried a default DLL build in the same environment; it assembled x86_64-gf2m.asm and built libeay32.dll with no issues; it failed on its way to the other DLL for reasons which I think are caused by my peculiar build environment.

The Shining Light distribution says it is a default build, makes no mention of having had to disable assembler. They don't give a lot of details of the build process, but I'd have thought disabling assembler would get a mention. I'm sure an x64 assembler DLL build is possible with the right tools.

> From: Phillip Hellewell [mailto:[hidden email]]
> Sent: Tuesday, May 21, 2013 1:04 AM
>
> On Mon, May 20, 2013 at 1:12 PM, Phillip Hellewell <[hidden email]>
> wrote:
> > Should I try to patch it myself?
>
> FYI, the linker error is occurring because nasm is failing with a ton
> of errors on x86_64-g2m.asm, I think maybe because it is creating the
> wrong type of asm.
>
> So I tried masm instead, and it is working sometimes, but sometimes I
> get this:
> tmp32dll\x86_64-gf2m.asm(1) : error A2088:END directive required at end
> of file
>
> Assuming I can get past that, the conclusion is that I have to use
> masm for 64-bit and nasm for 32-bit.  And since do_win64a.bat and
> other spots are set up to just use nasm automatically when available,
> I have to play a silly game in my build script where I hide nasm.exe
> from my path while building 64-bit, then put it back in my path while
> building 32-bit.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Build error with 1.0.1e on Win64 with VC++ 2010 and nasm

Jakob Bohm-7
In reply to this post by Phillip Hellewell-2
On 5/21/2013 2:04 AM, Phillip Hellewell wrote:

> On Mon, May 20, 2013 at 1:12 PM, Phillip Hellewell <[hidden email]> wrote:
>> Should I try to patch it myself?
>
> FYI, the linker error is occurring because nasm is failing with a ton
> of errors on x86_64-g2m.asm, I think maybe because it is creating the
> wrong type of asm.
>
> So I tried masm instead, and it is working sometimes, but sometimes I get this:
> tmp32dll\x86_64-gf2m.asm(1) : error A2088:END directive required at end of file
>
> Assuming I can get past that, the conclusion is that I have to use
> masm for 64-bit and nasm for 32-bit.  And since do_win64a.bat and
> other spots are set up to just use nasm automatically when available,
> I have to play a silly game in my build script where I hide nasm.exe
> from my path while building 64-bit, then put it back in my path while
> building 32-bit.
>

I have previously built 1.0.x for Win64 on x86_64 using Visual Studio
2005 with little or no problems, and the resulting libs link nicely with
VS2010, but I have not tested building OpenSSL itself on VS2010.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  http://www.wisemo.com
Transformervej 29, 2730 Herlev, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Build error with 1.0.1e on Win64 with VC++ 2010 and nasm

Dr. Stephen Henson
In reply to this post by Phillip Hellewell-2
On Mon, May 20, 2013, Phillip Hellewell wrote:

> On Mon, May 20, 2013 at 1:12 PM, Phillip Hellewell <[hidden email]> wrote:
> > Should I try to patch it myself?
>
> FYI, the linker error is occurring because nasm is failing with a ton
> of errors on x86_64-g2m.asm, I think maybe because it is creating the
> wrong type of asm.
>

Just tried it myself with Visual Studio 2012, nasm version 2.10.07 and it
compiles with no problems for me. I also tried it without nasm (i.e. ml64) and
that worked OK too.

Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Build error with 1.0.1e on Win64 with VC++ 2010 and nasm

Phillip Hellewell-2
On Tue, May 21, 2013 at 5:33 AM, Dr. Stephen Henson <[hidden email]> wrote:
> Just tried it myself with Visual Studio 2012, nasm version 2.10.07 and it
> compiles with no problems for me. I also tried it without nasm (i.e. ml64) and
> that worked OK too.

Ok, this is very helpful to know that it is working for other people,
just not me.  Somehow I knew it couldn't be possible for no one else
in the whole world to not want this.

So I went back and tried to execute some steps manually.  Sure enough,
I can assemble the x86_64-gf2m no problem, both when set up with masm,
and when using nasm.

But when executed from my build script (a batch file), it runs into
problems.  Based on the type of error I see, my only logical
conclusion is that maybe the assembler is running too quickly after
the perl script, i.e., before it has flushed the .asm to disk?  Is
that possible?

Phillip
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Build error with 1.0.1e on Win64 with VC++ 2010 and nasm

Phillip Hellewell-2
On Tue, May 21, 2013 at 9:08 AM, Phillip Hellewell <[hidden email]> wrote:
> But when executed from my build script (a batch file), it runs into
> problems.

Here is a copy of my build script.  Can anyone spot a problem with it?

@echo off
if "%1"=="" goto buildall

setlocal
cd /d "%~dp0.."
@call target\dependency\tools\prep.bat
@if errorlevel 1 goto errored
@echo off
set PERL5LIB=
call "%~dp0opensslver.bat"
path %cd%\perl\bin;%path%
cd openssl-%opensslVer%
if errorlevel 1 goto errored
if "%1"=="32" call "%VC10X32ENVBAT%"
if "%1"=="64" call "%VC10X64ENVBAT%"
if errorlevel 1 goto errored
perl --version > nul
if errorlevel 1 goto errored
echo Generating mak files with perl...
@if "%1"=="64" (
 perl Configure enable-md2 VC-WIN64A --prefix=./stage.%1
 call ms\do_win64a.bat
 rem batch file made the release mak files; now generate the debug ones
 perl util\mk1mf.pl debug dll VC-WIN64A > ms\ntdlld.mak
 perl util\mk1mf.pl debug VC-WIN64A > ms\ntd.mak
)
@if "%1"=="32" (
 perl Configure enable-md2 VC-WIN32 --prefix=./stage.%1
 call ms\do_nasm.bat
 rem batch file made the release mak files; now generate the debug ones
 perl util\mk1mf.pl debug dll VC-WIN32 > ms\ntdlld.mak
 perl util\mk1mf.pl debug VC-WIN32 > ms\ntd.mak
)
if not exist stage.%1 md stage.%1
if not exist stage.%1\bin md stage.%1\bin
perl util\mkdef.pl 32 libeay > ms\libeay32d.def
perl util\mkdef.pl 32 ssleay > ms\ssleay32d.def
echo Fixing up mak files
perl -p -i.bak -e
"s/SSL=ssleay32/SSL=ssleay32d/;s/CRYPTO=libeay32/CRYPTO=libeay32d/;s/SSLEAY32.def/\$(SSL).def/;s/LIBEAY32.def/\$(CRYPTO).def/;s/version32.rc/version32d.rc/;s/\/Fdout32dll/-Fdstage.%1\\bin\\openssld.pdb/;s/\/Od/-Od
-RTC1 -EHa/;s/RM=del/RM=del \/q/" ms\ntdlld.mak
perl -p -i.bak -e "s/\/Ox/-O2 -EHa -Zi
-DNDEBUG/;s/\/Fdout32dll/-Fdstage.%1\\bin\\openssl.pdb/;s/RM=del/RM=del
\/q/" ms\ntdll.mak
perl -p -i.bak -e "s/LIBEAY32/LIBEAY32D/" ms\libeay32d.def
perl -p -i.bak -e "s/SSLEAY32/SSLEAY32D/" ms\ssleay32d.def
perl -p -i.bak -e
"s/SSL=ssleay32/SSL=ssleay32ds/;s/CRYPTO=libeay32/CRYPTO=libeay32ds/;s/\/Fdout32/-Fdstage.%1\\lib\\openssld.pdb/;s/\/Od/-Od
-RTC1 -EHa/;s/RM=del/RM=del \/q/" ms\ntd.mak
perl -p -i.bak -e
"s/SSL=ssleay32/SSL=ssleay32s/;s/CRYPTO=libeay32/CRYPTO=libeay32s/;s/\/Ox/-O2
-EHa -Zi -Fdstage.%1\\lib\\openssl.pdb -DNDEBUG/;s/RM=del/RM=del \/q/"
ms\nt.mak
copy /y ms\version32.rc ms\version32d.rc
perl -p -i.bak -e
"s/libeay32.dll/libeay32d.dll/;s/ssleay32.dll/ssleay32d.dll/"
ms\version32d.rc
echo Building Release %1 DLL
@echo on
nmake -f ms\ntdll.mak clean > build-%1.log 2>&1
nmake -f ms\ntdll.mak >> build-%1.log 2>&1
@if errorlevel 1 goto errored
nmake -f ms\ntdll.mak install >> build-%1.log 2>&1
nmake -f ms\ntdll.mak clean >> build-%1.log 2>&1
echo Building Debug %1 DLL
nmake -f ms\ntdlld.mak clean >> build-%1.log 2>&1
nmake -f ms\ntdlld.mak >> build-%1.log 2>&1
@if errorlevel 1 goto errored
nmake -f ms\ntdlld.mak install >> build-%1.log 2>&1
nmake -f ms\ntdlld.mak clean >> build-%1.log 2>&1
@if errorlevel 1 goto errored
echo Building Release %1 Static
nmake -f ms\nt.mak clean >> build-%1.log 2>&1
nmake -f ms\nt.mak >> build-%1.log 2>&1
@if errorlevel 1 goto errored
nmake -f ms\nt.mak install >> build-%1.log 2>&1
nmake -f ms\nt.mak clean >> build-%1.log 2>&1
echo Building Debug %1 Static
nmake -f ms\ntd.mak clean >> build-%1.log 2>&1
nmake -f ms\ntd.mak >> build-%1.log 2>&1
@if errorlevel 1 goto errored
nmake -f ms\ntd.mak install >> build-%1.log 2>&1
nmake -f ms\ntd.mak clean >> build-%1.log 2>&1
@echo off
@exit /b 0

:buildall
setlocal
@call %0 64
@if errorlevel 1 goto errored
@call %0 32
@if errorlevel 1 goto errored
@exit /b 0

:errored
@echo An error occurred.
@exit /b 1

Thanks,
Phillip
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Build error with 1.0.1e on Win64 with VC++ 2010 and nasm

Phillip Hellewell-2
I forgot to mention, I am using perl.exe version 5.16.3 and nasm.exe
version 2.10.07.

Phillip
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Build error with 1.0.1e on Win64 with VC++ 2010 and nasm

Phillip Hellewell-2
Good news, I found the bug!  I got thinking, why is x86_64-gf2m the
only one giving me a problem?  So I compared x86_64-gf2m.pl to the
others and found that it has this line:
    open STDOUT,"| \"$^X\" $xlate $flavour $output";
whereas the others have this:
    open OUT,"| \"$^X\" $xlate $flavour $output";
    *STDOUT=*OUT;

I don't know perl well enough to understand the distinction between
these, but it is obviously important to use the latter :)

I'll submit a patch to the request tracker.

Phillip
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Build error with 1.0.1e on Win64 with VC++ 2010 and nasm

Viktor Dukhovni
On Tue, May 21, 2013 at 10:14:27AM -0600, Phillip Hellewell wrote:

> Good news, I found the bug!  I got thinking, why is x86_64-gf2m the
> only one giving me a problem?  So I compared x86_64-gf2m.pl to the
> others and found that it has this line:
>     open STDOUT,"| \"$^X\" $xlate $flavour $output";
> whereas the others have this:
>     open OUT,"| \"$^X\" $xlate $flavour $output";
>     *STDOUT=*OUT;
>
> I don't know perl well enough to understand the distinction between
> these, but it is obviously important to use the latter :)

A Windows specific Perl issue:

    https://rt.openssl.org/Ticket/Display.html?id=2963&user=guest&pass=guest

    http://old.nabble.com/nasm-intermittently-fails-to-assemble-a-file-td29947144.html

Most likely Perl's close() behaves differently on Windows for the
real STDOUT and does not wait for the child process if the STDOUT
file descriptor a pipe.  Reassigning STDOUT likely removes the
magic treatment.

If so, this is a Windows Perl bug IMHO.  The parent should wait
for the child to exit with close(STDOUT) in either scenario.
Any special treatment of STDOUT should be reset after

        open STDOUT,"|cmd";

in such a way as to ensure that wait() happens on close().

I've not had to jump through hoops like that using Perl on Unix
since Perl 0.9.  And while making Windows look like Unix is not
easy, one should not have to do this on Windows either.

Does anyone know whether this issue has been reported to the Perl
maintainers (and perhaps fixed in some sufficiently recent release)?

--
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Build error with 1.0.1e on Win64 with VC++ 2010 and nasm

Phillip Hellewell-2
On Tue, May 21, 2013 at 11:00 AM, Viktor Dukhovni
<[hidden email]> wrote:
> If so, this is a Windows Perl bug IMHO.  The parent should wait
> for the child to exit with close(STDOUT) in either scenario.
> Any special treatment of STDOUT should be reset after
>
>         open STDOUT,"|cmd";
>
> in such a way as to ensure that wait() happens on close().

Yeah, I would have to agree that it is a Windows Perl bug.
Nevertheless, that doesn't change the fact that openssl should work
around it if it can easily, which it can and does in the other
x86_64*.pl files.

> Does anyone know whether this issue has been reported to the Perl
> maintainers (and perhaps fixed in some sufficiently recent release)?

I am using the very latest version of ActivePerl, 5.16.3.1603, so it
hasn't been fixed.  I don't know if it has been reported.

Phillip
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]