Re: [patch] LNK4078 and LNK4210 linking with x64 static libs
On 19-10-2010 19:23, Jeffrey Walton wrote: So I wasted my precious time preparing a patch while someone else had already posted a patch off-list. Lol... If you're going to throw a tantrum every time someone beats you ta a patch, you owe us a tantrum: WinCE patch: http://www.mail-archive.com/openssl-users@openssl.org/msg61765.html Pierre Delaage submission: http://www.mail-archive.com/openssl-...@openssl.org/msg28264.html :) I don't mind someone patching it before me, that is fine. I mind that someone moved a discussion off-list without cross-posting to the original list or at least posting a FUT-like message to the original thread, specifying where exactly the discussion has been moved. This is general good practice, also to help those who might (much later) find the thread in Google and get only half the story. (The post suggesting that someone file a bug is not an exact FUT, a link to the bug number as soon as work began would have been). On Tue, Oct 19, 2010 at 7:20 AM, Jakob Bohmjb-open...@wisemo.com wrote: On 19-10-2010 12:32, per frykenvall wrote: Thanks, Jakob! However, I followed Dr. Stephen Hensons advice earlier in this thread and filed a report to the bug tracker, and got a resolution from Andy Polyakov a week ago, based on your suggestion. I've tested it and am fully satisfied: [openssl.org #2356] Resolved: LNK4078 and LNK4210 linking with x64 static libs http://cvs.openssl.org/chngview?cn=19935 So I wasted my precious time preparing a patch while someone else had already posted a patch off-list. Thanks to everyone involved for not telling the list that this issue had been resolved in another forum! Of course, that resolution does not include the race condition you describe. Best regards, Per On 2010-10-18 17:35, Jakob Bohm wrote: I have now created an actual patch to fix this. It turns out to be a small pattern bug in x86_64xlate.pl Patch attached as openssl-1.0.0a-x86_64attr.patch. While debugging this patch I ran into an unrelated issue where nmake would invoke nasm before the .asm file had been completely output. This is probably a bug in the perl build used on one of the test machines, but I think the patch to kludge around that race condition might be useful too. Patch attached as openssl-1.0.0a-x86_64cpuid-build-race.patch. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [patch] LNK4078 and LNK4210 linking with x64 static libs
Thanks, Jakob! However, I followed Dr. Stephen Hensons advice earlier in this thread and filed a report to the bug tracker, and got a resolution from Andy Polyakov a week ago, based on your suggestion. I've tested it and am fully satisfied: [openssl.org #2356] Resolved: LNK4078 and LNK4210 linking with x64 static libs http://cvs.openssl.org/chngview?cn=19935 Of course, that resolution does not include the race condition you describe. Best regards, Per On 2010-10-18 17:35, Jakob Bohm wrote: I have now created an actual patch to fix this. It turns out to be a small pattern bug in x86_64xlate.pl Patch attached as openssl-1.0.0a-x86_64attr.patch. While debugging this patch I ran into an unrelated issue where nmake would invoke nasm before the .asm file had been completely output. This is probably a bug in the perl build used on one of the test machines, but I think the patch to kludge around that race condition might be useful too. Patch attached as openssl-1.0.0a-x86_64cpuid-build-race.patch. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [patch] LNK4078 and LNK4210 linking with x64 static libs
On 19-10-2010 12:32, per frykenvall wrote: Thanks, Jakob! However, I followed Dr. Stephen Hensons advice earlier in this thread and filed a report to the bug tracker, and got a resolution from Andy Polyakov a week ago, based on your suggestion. I've tested it and am fully satisfied: [openssl.org #2356] Resolved: LNK4078 and LNK4210 linking with x64 static libs http://cvs.openssl.org/chngview?cn=19935 So I wasted my precious time preparing a patch while someone else had already posted a patch off-list. Thanks to everyone involved for not telling the list that this issue had been resolved in another forum! Of course, that resolution does not include the race condition you describe. Best regards, Per On 2010-10-18 17:35, Jakob Bohm wrote: I have now created an actual patch to fix this. It turns out to be a small pattern bug in x86_64xlate.pl Patch attached as openssl-1.0.0a-x86_64attr.patch. While debugging this patch I ran into an unrelated issue where nmake would invoke nasm before the .asm file had been completely output. This is probably a bug in the perl build used on one of the test machines, but I think the patch to kludge around that race condition might be useful too. Patch attached as openssl-1.0.0a-x86_64cpuid-build-race.patch. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [patch] LNK4078 and LNK4210 linking with x64 static libs
Hi, I was not involved in this discussion, but I wanted just to say that patches and other development issues are discussed in the openssl-dev list and all messages sent to r...@openssl.org are also copied to that list not the users list. Anyone interested in OpenSSL internals should join openssl-dev to be kept updated. That being said, I understand your frustration but the others certainly thought you were aware of their discussion in the other list. Cheers, -- Mounir IDRASSI IDRIX http://www.idrix.fr On 10/19/2010 1:20 PM, Jakob Bohm wrote: On 19-10-2010 12:32, per frykenvall wrote: Thanks, Jakob! However, I followed Dr. Stephen Hensons advice earlier in this thread and filed a report to the bug tracker, and got a resolution from Andy Polyakov a week ago, based on your suggestion. I've tested it and am fully satisfied: [openssl.org #2356] Resolved: LNK4078 and LNK4210 linking with x64 static libs http://cvs.openssl.org/chngview?cn=19935 So I wasted my precious time preparing a patch while someone else had already posted a patch off-list. Thanks to everyone involved for not telling the list that this issue had been resolved in another forum! Of course, that resolution does not include the race condition you describe. Best regards, Per On 2010-10-18 17:35, Jakob Bohm wrote: I have now created an actual patch to fix this. It turns out to be a small pattern bug in x86_64xlate.pl Patch attached as openssl-1.0.0a-x86_64attr.patch. While debugging this patch I ran into an unrelated issue where nmake would invoke nasm before the .asm file had been completely output. This is probably a bug in the perl build used on one of the test machines, but I think the patch to kludge around that race condition might be useful too. Patch attached as openssl-1.0.0a-x86_64cpuid-build-race.patch. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [patch] LNK4078 and LNK4210 linking with x64 static libs
So I wasted my precious time preparing a patch while someone else had already posted a patch off-list. Lol... If you're going to throw a tantrum every time someone beats you ta a patch, you owe us a tantrum: WinCE patch: http://www.mail-archive.com/openssl-users@openssl.org/msg61765.html Pierre Delaage submission: http://www.mail-archive.com/openssl-...@openssl.org/msg28264.html :) On Tue, Oct 19, 2010 at 7:20 AM, Jakob Bohm jb-open...@wisemo.com wrote: On 19-10-2010 12:32, per frykenvall wrote: Thanks, Jakob! However, I followed Dr. Stephen Hensons advice earlier in this thread and filed a report to the bug tracker, and got a resolution from Andy Polyakov a week ago, based on your suggestion. I've tested it and am fully satisfied: [openssl.org #2356] Resolved: LNK4078 and LNK4210 linking with x64 static libs http://cvs.openssl.org/chngview?cn=19935 So I wasted my precious time preparing a patch while someone else had already posted a patch off-list. Thanks to everyone involved for not telling the list that this issue had been resolved in another forum! Of course, that resolution does not include the race condition you describe. Best regards, Per On 2010-10-18 17:35, Jakob Bohm wrote: I have now created an actual patch to fix this. It turns out to be a small pattern bug in x86_64xlate.pl Patch attached as openssl-1.0.0a-x86_64attr.patch. While debugging this patch I ran into an unrelated issue where nmake would invoke nasm before the .asm file had been completely output. This is probably a bug in the perl build used on one of the test machines, but I think the patch to kludge around that race condition might be useful too. Patch attached as openssl-1.0.0a-x86_64cpuid-build-race.patch. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: [patch] LNK4078 and LNK4210 linking with x64 static libs
I have now created an actual patch to fix this.
It turns out to be a small pattern bug in x86_64xlate.pl
Patch attached as openssl-1.0.0a-x86_64attr.patch.
While debugging this patch I ran into an unrelated issue where nmake
would invoke nasm before the .asm file had been completely output.
This is probably a bug in the perl build used on one of the test
machines, but I think the patch to kludge around that race condition
might be useful too.
Patch attached as openssl-1.0.0a-x86_64cpuid-build-race.patch.
Comment: This patch fixes incorrect attributes of the .init segment in
translated assemply for x86_64 when linked with Visual C code.
This fix is applicable even if it is also decided to not use an .init
seg anymore in x86_64cpuid.pl.
Author: WiseMo A/S, licensed under the Openssl license
diff -Naur openssl-1.0.0a.orig/crypto/perlasm/x86_64-xlate.pl
openssl-1.0.0a/crypto/perlasm/x86_64-xlate.pl
--- openssl-1.0.0a.orig/crypto/perlasm/x86_64-xlate.pl 2010-06-01
05:57:26.0 +
+++ openssl-1.0.0a/crypto/perlasm/x86_64-xlate.pl 2010-10-13
17:53:21.0 +
@@ -542,16 +542,16 @@
$line = .CRT\$XCU if ($line eq .init);
if ($nasm) {
$v=section $line;
- if ($line=~/\.([px])data/) {
+ if ($line=~/\.(pdata|xdata|CRT\$)/) {
$v.= rdata align=;
- $v.=$1 eq p? 4 : 8;
+ $v.=$1 eq pdata? 4 : 8;
}
} else {
$v=$current_segment\tENDS\n if
($current_segment);
$v.=$line\tSEGMENT;
- if ($line=~/\.([px])data/) {
+ if ($line=~/\.(pdata|xdata|CRT\$)/) {
$v.= READONLY;
- $v.= ALIGN(.($1 eq p ? 4 :
8).) if ($masm=$masmref);
+ $v.= ALIGN(.($1 eq pdata ? 4 :
8).) if ($masm=$masmref);
}
}
$current_segment = $line;
Comment: Some perl interpreters will not always wait for the child pipe
filter to exit before the parent perl interpreter exits (on platforms
where doing so does not kill the filter process). This in turn causes
a race condition between the x86_64-xlate.pl script and make invoking the
assembler on the output file.
This patch tries harder to avoid that race condition by increasing the
flush mode of perl just before closing the pipe AND adding a grace sleep
after closing the pipe.
Author: WiseMo A/S, licensed under the Openssl license
diff -Naur openssl-1.0.0a.orig/crypto/x86_64cpuid.pl
openssl-1.0.0a/crypto/x86_64cpuid.pl
--- openssl-1.0.0a.orig/crypto/x86_64cpuid.pl 2010-04-14 19:25:09.0
+
+++ openssl-1.0.0a/crypto/x86_64cpuid.pl2010-10-13 17:31:32.0
+
@@ -229,4 +229,6 @@
.size OPENSSL_wipe_cpu,.-OPENSSL_wipe_cpu
___
+$|=1; # flush more thoroughly
close STDOUT; # flush
+sleep(2); # Break race against background pipe completion
Re: LNK4078 and LNK4210 linking with x64 static libs
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 EFFB 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 Jakob Bohm wrote: Update, 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. On 23-09-2010 16:05, Jakob Bohm wrote: Actually, that section (specifically, the DQ line) places a single 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 0x6020 (meaning Read/Execute, contains code), even though the rest of the file section it ultimately goes into (.rdata) has attributes 0x4040 (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. On 23-09-2010 15:09, Jack Zhang wrote: According to my understanding, that section is just a declaration of an external function. The section is needed to be there only if the function is called in the x86_64cpuid.asm. So, I don't think it will affect anything. In fact, my x64 version build runs perfectly. (I am using openssl 1.0.0 and then 1.0.0a) On Thu, Sep 23, 2010 at 7:12 AM, per fry kenvall per...@got.wmdata.se mailto:per...@got.wmdata.se wrote: Hi, 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 On Tue, Sep 21, 2010 at 9:57 AM, perfry wrote: Hi, I've built 1.0.0a on Windows 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' (6020) merged into '.rdata' (4040) with different attributes And when linking our own application on x64/Release platform: libeay32.lib(x86_64cpuid.obj) : warning
Re: LNK4078 and LNK4210 linking with x64 static libs
On Mon, Oct 04, 2010, per frykenvall wrote: 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 EFFB 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 __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: LNK4078 and LNK4210 linking with x64 static libs
Try no-asm: 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 -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Jakob Bohm Sent: Thursday, September 30, 2010 5:53 PM To: openssl-users@openssl.org Subject: Re: LNK4078 and LNK4210 linking with x64 static libs Update, 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. On 23-09-2010 16:05, Jakob Bohm wrote: Actually, that section (specifically, the DQ line) places a single 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 0x6020 (meaning Read/Execute, contains code), even though the rest of the file section it ultimately goes into (.rdata) has attributes 0x4040 (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. On 23-09-2010 15:09, Jack Zhang wrote: According to my understanding, that section is just a declaration of an external function. The section is needed to be there only if the function is called in the x86_64cpuid.asm. So, I don't think it will affect anything. In fact, my x64 version build runs perfectly. (I am using openssl 1.0.0 and then 1.0.0a) On Thu, Sep 23, 2010 at 7:12 AM, per fry kenvall per...@got.wmdata.se mailto:per...@got.wmdata.se wrote: Hi, 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 On Tue, Sep 21, 2010 at 9:57 AM, perfry wrote: Hi, I've built 1.0.0a on Windows 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' (6020) merged into '.rdata' (4040) 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
Re: LNK4078 and LNK4210 linking with x64 static libs
Update, 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. On 23-09-2010 16:05, Jakob Bohm wrote: Actually, that section (specifically, the DQ line) places a single 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 0x6020 (meaning Read/Execute, contains code), even though the rest of the file section it ultimately goes into (.rdata) has attributes 0x4040 (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. On 23-09-2010 15:09, Jack Zhang wrote: According to my understanding, that section is just a declaration of an external function. The section is needed to be there only if the function is called in the x86_64cpuid.asm. So, I don't think it will affect anything. In fact, my x64 version build runs perfectly. (I am using openssl 1.0.0 and then 1.0.0a) On Thu, Sep 23, 2010 at 7:12 AM, per fry kenvall per...@got.wmdata.se mailto:per...@got.wmdata.se wrote: Hi, 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 On Tue, Sep 21, 2010 at 9:57 AM, perfry wrote: Hi, I've built 1.0.0a on Windows 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' (6020) merged into '.rdata' (4040) 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\RSP132444832.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
Re: LNK4078 and LNK4210 linking with x64 static libs
Hi, again, 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 wrote: Actually, that section (specifically, the DQ line) places a single 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 0x6020 (meaning Read/Execute, contains code), even though the rest of the file section it ultimately goes into (.rdata) has attributes 0x4040 (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. On 23-09-2010 15:09, Jack Zhang wrote: According to my understanding, that section is just a declaration of an external function. The section is needed to be there only if the function is called in the x86_64cpuid.asm. So, I don't think it will affect anything. In fact, my x64 version build runs perfectly. (I am using openssl 1.0.0 and then 1.0.0a) On Thu, Sep 23, 2010 at 7:12 AM, per fry kenvall per...@got.wmdata.se mailto:per...@got.wmdata.se wrote: Hi, 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 EXTERNOPENSSL_cpuid_setup section.CRT$XCU ALIGN8 DQOPENSSL_cpuid_setup section.text code align=64 from the asm file because the extern OpenSSL_cpuid_setup is never referenced. Good luck On Tue, Sep 21, 2010 at 9:57 AM, perfry wrote: Hi, I've built 1.0.0a on Windows 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' (6020) merged into '.rdata' (4040) 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\RSP132444832.rsp with contents [
Re: LNK4078 and LNK4210 linking with x64 static libs
Hi, 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 EXTERNOPENSSL_cpuid_setup section.CRT$XCU ALIGN8 DQOPENSSL_cpuid_setup section.text code align=64 from the asm file because the extern OpenSSL_cpuid_setup is never referenced. Good luck On Tue, Sep 21, 2010 at 9:57 AM, perfry wrote: Hi, I've built 1.0.0a on Windows 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' (6020) merged into '.rdata' (4040) 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\RSP132444832.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\RSP132444832.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: defaultrel EXTERNOPENSSL_cpuid_setup section.CRT$XCU ALIGN8 DQOPENSSL_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 openssl-users@openssl.org mailto:openssl-users@openssl.org Automated List Manager majord...@openssl.org mailto:majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: LNK4078 and LNK4210 linking with x64 static libs
According to my understanding, that section is just a declaration of an external function. The section is needed to be there only if the function is called in the x86_64cpuid.asm. So, I don't think it will affect anything. In fact, my x64 version build runs perfectly. (I am using openssl 1.0.0 and then 1.0.0a) On Thu, Sep 23, 2010 at 7:12 AM, per fry kenvall per...@got.wmdata.sewrote: Hi, 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 EXTERNOPENSSL_cpuid_setup section.CRT$XCU ALIGN8 DQOPENSSL_cpuid_setup section.text code align=64 from the asm file because the extern OpenSSL_cpuid_setup is never referenced. Good luck On Tue, Sep 21, 2010 at 9:57 AM, perfry wrote: Hi, I've built 1.0.0a on Windows 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' (6020) merged into '.rdata' (4040) 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\RSP132444832.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\RSP132444832.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: defaultrel EXTERNOPENSSL_cpuid_setup section.CRT$XCU ALIGN8 DQOPENSSL_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 openssl-users@openssl.org mailto:openssl-users@openssl.org Automated List Manager majord...@openssl.org mailto:majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager
Re: LNK4078 and LNK4210 linking with x64 static libs
Actually, that section (specifically, the DQ line) places a single 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 0x6020 (meaning Read/Execute, contains code), even though the rest of the file section it ultimately goes into (.rdata) has attributes 0x4040 (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. On 23-09-2010 15:09, Jack Zhang wrote: According to my understanding, that section is just a declaration of an external function. The section is needed to be there only if the function is called in the x86_64cpuid.asm. So, I don't think it will affect anything. In fact, my x64 version build runs perfectly. (I am using openssl 1.0.0 and then 1.0.0a) On Thu, Sep 23, 2010 at 7:12 AM, per fry kenvall per...@got.wmdata.se mailto:per...@got.wmdata.se wrote: Hi, 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 EXTERNOPENSSL_cpuid_setup section.CRT$XCU ALIGN8 DQOPENSSL_cpuid_setup section.text code align=64 from the asm file because the extern OpenSSL_cpuid_setup is never referenced. Good luck On Tue, Sep 21, 2010 at 9:57 AM, perfry wrote: Hi, I've built 1.0.0a on Windows 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' (6020) merged into '.rdata' (4040) 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\RSP132444832.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
Re: LNK4078 and LNK4210 linking with x64 static libs
I disagree; according to 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 callOPENSSL_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 Jack Zhang wrote: According to my understanding, that section is just a declaration of an external function. The section is needed to be there only if the function is called in the x86_64cpuid.asm. So, I don't think it will affect anything. In fact, my x64 version build runs perfectly. (I am using openssl 1.0.0 and then 1.0.0a) On Thu, Sep 23, 2010 at 7:12 AM, per fry kenvall per...@got.wmdata.se mailto:per...@got.wmdata.se wrote: Hi, 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 EXTERNOPENSSL_cpuid_setup section.CRT$XCU ALIGN8 DQOPENSSL_cpuid_setup section.text code align=64 from the asm file because the extern OpenSSL_cpuid_setup is never referenced. Good luck On Tue, Sep 21, 2010 at 9:57 AM, perfry wrote: Hi, I've built 1.0.0a on Windows 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' (6020) merged into '.rdata' (4040) 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\RSP132444832.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\RSP132444832.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
LNK4078 and LNK4210 linking with x64 static libs
Hi, (please excuse if this is a duplicate, yesterdays posting 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' (6020) merged into '.rdata' (4040) 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\RSP132444832.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\RSP132444832.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: defaultrel EXTERNOPENSSL_cpuid_setup section.CRT$XCU ALIGN8 DQOPENSSL_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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
LNK4078 and LNK4210 linking with x64 static libs
Hi, I've built 1.0.0a on Windows 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' (6020) merged into '.rdata' (4040) 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\RSP132444832.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\RSP132444832.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: defaultrel EXTERNOPENSSL_cpuid_setup section.CRT$XCU ALIGN8 DQOPENSSL_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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: LNK4078 and LNK4210 linking with x64 static libs
I had got the same problem. I just simply deleted that section EXTERNOPENSSL_cpuid_setup section.CRT$XCU ALIGN8 DQOPENSSL_cpuid_setup section.text code align=64 from the asm file because the extern OpenSSL_cpuid_setup is never referenced. Good luck On Tue, Sep 21, 2010 at 9:57 AM, perfry per.frykenv...@naturskyddsforeningen.se wrote: Hi, I've built 1.0.0a on Windows 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' (6020) merged into '.rdata' (4040) 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\RSP132444832.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\RSP132444832.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: defaultrel EXTERNOPENSSL_cpuid_setup section.CRT$XCU ALIGN8 DQOPENSSL_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 Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
