Re: Compile 0.9.8x for 64bit is missing _SHA* symbols

2013-01-11 Thread Jeffrey Walton
On Fri, Jan 11, 2013 at 7:45 AM, Ribhi Kamal wrote: > I guess the next time I see a linker complain about _ I'll know what's > wrong :) Absolutely. I've done the same many times, and that's why I knew :) > On Fri, Jan 11, 2013 at 6:07 AM, Michel wrote: >> >> >> Found interresting related article

Re: Compile 0.9.8x for 64bit is missing _SHA* symbols

2013-01-11 Thread Ribhi Kamal
I guess the next time I see a linker complain about _ I'll know what's wrong :) Thanks for the help On Fri, Jan 11, 2013 at 6:07 AM, Michel wrote: > > Found interresting related article from Wikipedia : > http://en.wikipedia.org/wiki/**Name_mangling

Re: Compile 0.9.8x for 64bit is missing _SHA* symbols

2013-01-11 Thread Michel
Found interresting related article from Wikipedia : http://en.wikipedia.org/wiki/Name_mangling "Note that the 64-bit convention on Windows (Microsoft C) is no leading underscore. This difference may in some rare cases lead to unresolved externals when porting such code to 64 bits. " Le 11/01

RE: Compile 0.9.8x for 64bit is missing _SHA* symbols

2013-01-10 Thread Dave Thompson
>From: owner-openssl-us...@openssl.org On Behalf Of Ribhi Kamal >Sent: Thursday, 10 January, 2013 17:51 >Never mind, the application (virtualbox) was incorrectly trying to use >the 32bit version of openssl. But I still don't understand why a 32bit >version has different symbols that the 64bit on

Re: Compile 0.9.8x for 64bit is missing _SHA* symbols

2013-01-10 Thread Jeffrey Walton
On Thu, Jan 10, 2013 at 6:33 PM, Ribhi Kamal wrote: > So even though the names differ by a prefixed underscore in ( _SHA1_Update > vs SHA1_Update ), the names are actually the same? I wonder what linker > logic is behind this Yes. That's a 'C' decoration. The underscore'd name is what the linker s

Re: Compile 0.9.8x for 64bit is missing _SHA* symbols

2013-01-10 Thread Ribhi Kamal
So even though the names differ by a prefixed underscore in ( _SHA1_Update vs SHA1_Update ), the names are actually the same? I wonder what linker logic is behind this Thanks for the help, RK On Thu, Jan 10, 2013 at 6:09 PM, Jeffrey Walton wrote: > On Thu, Jan 10, 2013 at 5:50 PM, Ribhi Kamal

Re: Compile 0.9.8x for 64bit is missing _SHA* symbols

2013-01-10 Thread Jeffrey Walton
On Thu, Jan 10, 2013 at 5:50 PM, Ribhi Kamal wrote: > Never mind, the application (virtualbox) was incorrectly trying to use the > 32bit version of openssl. But I still don't understand why a 32bit version > has different symbols that the 64bit one. The message is probably similar to "Symbol not f

Re: Compile 0.9.8x for 64bit is missing _SHA* symbols

2013-01-10 Thread Ribhi Kamal
Never mind, the application (virtualbox) was incorrectly trying to use the 32bit version of openssl. But I still don't understand why a 32bit version has different symbols that the 64bit one. On Thu, Jan 10, 2013 at 12:01 PM, Ribhi Kamal wrote: > Thanks Jakob, I'm using MASM (ml and ml64) and i

Re: Compile 0.9.8x for 64bit is missing _SHA* symbols

2013-01-10 Thread Ribhi Kamal
Thanks Jakob, I'm using MASM (ml and ml64) and it seems to work ok for the 32bit build at least. Should I be using nasm for 64bit instead? The functionality for SHA512 and the rest seems to be implemented because the test for SHA512 (sha512t.exe) is compiled and works correctly. And I think the sy

Re: Compile 0.9.8x for 64bit is missing _SHA* symbols

2013-01-10 Thread Jakob Bohm
On 1/9/2013 6:40 PM, Ribhi Kamal wrote: Hi all, I've compiled openssl 0.9.8x on windows 7 using VS2010 pro using the following steps: perl Configure VC-WIN64A --prefix=%LIB_OUT% CALL ms\do_win64a nmake -f ms\ntdll.mak nmake -f ms\ntdll.mak test nmake -f ms\ntdll.mak install Unfortunately the res

Compile 0.9.8x for 64bit is missing _SHA* symbols

2013-01-09 Thread Ribhi Kamal
Hi all, I've compiled openssl 0.9.8x on windows 7 using VS2010 pro using the following steps: perl Configure VC-WIN64A --prefix=%LIB_OUT% CALL ms\do_win64a nmake -f ms\ntdll.mak nmake -f ms\ntdll.mak test nmake -f ms\ntdll.mak install Unfortunately the resulting libraries do not have any of the fo