LNK4078 and LNK4210 linking with x64 static libs
per fry kenvall
seems failed)
I have problems with warnings from the linker on Windows, indicating
that initializers will not be called. I've built 1.0.0a with VS2005,
using nt.mak to get static libraries.
With x64 I get warnings when linking applications, both openssl.exe and
test programs like sha1test.exe. A snippet of output from nmake -f
ms\nt.mak:
link /nologo /subsystem:console /opt:ref /debug
/out:out32\openssl.exe @C:\DOCUME~1\FRYKEN~1\LOCALS~1\Temp\nm3B3.tmp
LIBCMT.lib(crt0init.obj) : warning LNK4254: section '.CRT' (60000020)
merged into '.rdata' (40000040) with different attributes
And when linking our own application on x64/Release platform:
libeay32.lib(x86_64cpuid.obj) : warning LNK4078: multiple '.CRT'
sections found with different attributes (60500020)
libeay32.lib(x86_64cpuid.obj) : warning LNK4210: .CRT section exists;
there may be unhandled static initializers or terminators
The linker command can be deduced from the following:
Creating temporary file
"c:\utv\ccbas4\ccbase\x64\Release\RSP0000132444832.rsp" with contents
[
/OUT:"../deploy/execs/x64/Release/etnode.exe" /INCREMENTAL:NO
/MANIFEST /MANIFESTFILE:"x64/Release\etnode.exe.intermediate.manifest"
/DELAYLOAD:"oci.dll" /DEBUG
/PDB:"../deploy/execs/x64/Release/etnode.pdb" /SUBSYSTEM:CONSOLE /LTCG
psapi.lib odbc32.lib odbccp32.lib WS2_32.LIB ADVAPI32.LIB GDI32.LIB
USER32.LIB dbghelp.lib
../snibu/logging-log4cxx/msvc/lib/x64/Release/log4cxxs.lib
../snibu/openssl-1.0.0a/x64/Release/lib/ssleay32.lib
../snibu/openssl-1.0.0a/x64/Release/lib/libeay32.lib
../snibu/oracle/x64/instantclient_10_2/sdk/lib/msvc/oci.lib
../snibu/zlib/msvc/lib/x64/Release/zlibstat.lib kernel32.lib user32.lib
gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib
oleaut32.lib uuid.lib odbc32.lib odbccp32.lib DelayImp.lib
".\x64\Release\CCcServApp.obj"
...
".\x64\Release\Bas4Bridge.obj"
]
Creating command line "link.exe
@c:\utv\ccbas4\ccbase\x64\Release\RSP0000132444832.rsp /NOLOGO
/ERRORREPORT:PROMPT"
I've done the following to build openssl:
cd /d C:\utv\snibu\openssl\x64\release\openssl-1.0.0a
call "C:\Program Files\Microsoft Visual Studio 8\VC\vcvarsall.bat"
x86_amd64
perl Configure VC-WIN64A --prefix=c:\appl\openssl-1.0.0a\x64\release
ms\do_win64a.bat
nmake -f ms\nt.mak
nmake -f ms\nt.mak install
And the file x86_64cpuid.asm mentioned in the warnings starts with the
following:
default rel
EXTERN OPENSSL_cpuid_setup
section .CRT$XCU
ALIGN 8
DQ OPENSSL_cpuid_setup
section .text code align=64
...
Could somebody help me solve this warning, it seems to me that
OPENSSL_cpuid_setup will not be executed.
Best regards,
Per Frykenvall
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openss...@openssl.org
Automated List Manager majo...@openssl.org
perfry
I've built 1.0.0a on Windows with VS2005, using nt.mak to get static
Jack Zhang
section .CRT$XCU
ALIGN 8
DQ OPENSSL_cpuid_setup
section .text code align=64
per fry kenvall
Thanks for your suggestion! But as far as I see, the assembler code in
x86_64cpuid.asm _is_ the reference to OPENSSL_cpuid_setup! The runtime
will call the functions given in the .CRT$XCU section before calling the
main() entry. And it seems to me that the OPENSSL_cpuid_setup function
in crypto/cryptlib.c does have useful code on Windows platforms, and so
should be called, shouldn't it? It initializes a static variable with
some processor specific info, whose value may be taken via the
OPENSSL_ia32cap_loc() function.
I tried printf("%lu", *OPENSSL_ia32cap_loc()), which prints out 0 using
the x64 code, while printing 2951479295 using 32-bit code, indicating
that OPENSSL_cpuid_setup has only been executed with the 32-bit code.
What's the impact of this? Isn't it a bug?
Cheers,
Per
Jack Zhang wrote:
> I had got the same problem. I just simply deleted that section
> EXTERN OPENSSL_cpuid_setup
> section .CRT$XCU
> ALIGN 8
> DQ OPENSSL_cpuid_setup
>
> section .text code align=64
>
> from the asm file because the extern OpenSSL_cpuid_setup is never
> referenced.
>
> Good luck
>
> openss...@openssl.org <mailto:openss...@openssl.org>
> Automated List Manager
> majo...@openssl.org <mailto:majo...@openssl.org>
Jack Zhang
Jakob Bohm
pointer constant in a data section with the "magic" name ".CRT$XCU".
Background:
The Microsoft linker, upon seeing a $ sign in a section name will
merge this section with all other sections name ".CRT" or
".CRT$whatever", but only after it has ordered the layout of that
section alphabetically according to the non-truncated section name.
Thus the constants in .obj section ".CRT$XCU" will be placed between
anything in sections ".CRT$XCT" (or less) and anything in sections
".CRT$XCV" (or more).
The Microsoft C runtime startup code contains declarations for dummy
NULL variables in sections ".CRT$XCA" and ".CRT$XCZ" and a loop
which treats the data between those sections (including the DQ placed
there by this ASM file and any constructors for C++ global variables
etc.) as an array of function pointers to be called before
invoking main(). A similar method (with a different letter after X
is used for functions to call after main() returns or during a call to
exit()).
The above description matches at least the C runtime in Visual Studio
2005 (look at the files VC\CRT\src\crt0init.c and VC\CRT\src\crt0dat.c).
Error message analysis:
The warning complains that something in section .CRT has been given
the section attributes 0x60000020 (meaning Read/Execute, contains code),
even though the rest of the file section it ultimately goes into
(".rdata") has attributes 0x40000040 (meaning Read, contains initialized
data).
Thus my guess is that the line "section .CRT$XCU" is lacking
some keywords to tell the assembler to mark that section as
read-only data, not code. Unfortunately, I am not sure of the
syntax to do that in the x86_64 version of MASM.
> <mailto:openss...@openssl.org
> <mailto:openss...@openssl.org>>
> Automated List Manager majo...@openssl.org
> <mailto:majo...@openssl.org> <mailto:majo...@openssl.org
per fry kenvall
http://blogs.msdn.com/b/vcblog/archive/2006/10/20/crt-initialization.aspx
.CRT$XCU is for setting up static initializers. Also, the text of the
source file from which the assembler file is generated gives a hint that
it is a call:
.extern OPENSSL_cpuid_setup
.section .init
call OPENSSL_cpuid_setup
And maybe the parts of openssl that you are using work perfectly, while
there might be other parts relying on this initialization.
(Unfortunately I can't run "make test" on 64-bit as I don't have any
such box with Visual Studio).
/Per
per frykenvall
Could anybody with insight in the OPENSSL_cpuid_setup have a look at
this issue? What is the impact when it doesn't get called on win x64?
Does the section need some flag? I haven't found any resolution to the
problem.
Best regards,
Per Frykenvall
Jakob Bohm
According to the NASM manual at
http://www.nasm.us/doc/nasmdoc7.html#section-7.5.1
The following change to the generated .asm file should fix this
without having to modify .obj files:
Current:
section .CRT$XCU
Fixed:
section .CRT$XCU rdata align=8
I have not yet tested this.
Rubin, RaizyX
call C:\Program Files\Microsoft Visual Studio 8\VC\bin\x86_amd64\vcvarsx86_amd64.bat
cd openssl
perl Configure VC-WIN64A no-asm --prefix="c:\appl\openssl-1.0.0a\x64\release"
ms\do_win64a.bat
nmake -f ms\nt.mak
nmake -f ms\nt.mak install
Update,
http://www.nasm.us/doc/nasmdoc7.html#section-7.5.1
Current:
section .CRT$XCU
Fixed:
section .CRT$XCU rdata align=8
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
per frykenvall
in tmp32/x86_64cpuid.asm helped. At least the warnings disappeared, and
*OPENSSL_ia32cap_loc() is now EFFBFFFF instead of 0.
So, the instructions to build on windows x64 would be:
* call "C:\Program Files\Microsoft Visual Studio 8\VC\vcvarsall.bat"
x86_amd64
or open a Visual Studio 2005 x64 Cross Tools Command Prompt
* perl Configure VC-WIN64A --prefix=c:\some\directory
* ms\do_win64a.bat
* Edit tmp32/x86_64cpuid.asm so that the third line reads: section
.CRT$XCU rdata align=8
* nmake -f ms\nt.mak
* nmake -f ms\nt.mak install
Could someone fix this permanently in the perl script in crypto/perlasm
that generates the section directive?
Again, thanks!
/Per
Dr. Stephen Henson
> Thanks a lot, Jakob! Adding "rdata align=8" to the section declaration in
> tmp32/x86_64cpuid.asm helped. At least the warnings disappeared, and
> *OPENSSL_ia32cap_loc() is now EFFBFFFF instead of 0.
>
> So, the instructions to build on windows x64 would be:
> * call "C:\Program Files\Microsoft Visual Studio 8\VC\vcvarsall.bat"
> x86_amd64
> or open a Visual Studio 2005 x64 Cross Tools Command Prompt
> * perl Configure VC-WIN64A --prefix=c:\some\directory
> * ms\do_win64a.bat
> * Edit tmp32/x86_64cpuid.asm so that the third line reads: section
> .CRT$XCU rdata align=8
> * nmake -f ms\nt.mak
> * nmake -f ms\nt.mak install
>
> Could someone fix this permanently in the perl script in crypto/perlasm
> that generates the section directive?
>
Please send a report to the request tracker so it doesn't get overlooked.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org