I am having a problem linking static libraries on for 32bit windows. I've got everything setup and working on Ubuntu 12.04 and have built one project which targets i386-linux, i386-win32, and x86_64-win64.
I'm using mingw-w64 on Ubuntu to create static lirbaries for openssl and the ssl crypto library.
The problem:
I can build and run my application on linux (i386-linux) and 64bit windows (x86_64-win64), but it fails to link properly when I target 32bit windows (i386-win32). The errors I am getting when I link for i386-win32 are:
Error: Undefined symbol: __time32
Undefined symbol: __localtime32
Undefined symbol: __gmtime32
There were 3 errors compiling module, stopping
I do not get these error when targeting x86_64-win64 and my test app run perfectly on 64bit windows.
Building a pascal application which links to two openssl static library files. Here is a snippet of my source code:
// Unit to link a static openssl library to my pascal applications
// With this unit I can build a single exe with no external dependencies
unit CryptoLib;
{$i cross.inc}
interface
const
SSL_ERROR_NONE = 0;
// snip ...{ SSL routines }
function SSL_library_init: Integer; cdecl; external;
// snip ...{ Hashing routines }
function MD5_Init(out context: TMD5Ctx): LongBool; cdecl; external;
// snip ...
// if were using window i pull in ming-w64 libraries
{$ifdef windows}
// pulled in from x86_64-w64-mingw32/lib or i686-w64-mingw32/lib
// as determined by project target cpu
// these libs satisfy the compiler
{$linklib msvcrt}
{$linklib user32}
{$linklib kernel32}
{$linklib ws2_32}
{$linklib advapi32}
{$linklib gdi32}
// libgcc.a is placed in project i386-win32 and x86_64-win64 folders, i
copy it from
// /usr/lib/gcc/i686-w64-mingw32/4.6
and /usr/lib/gcc/x86_64-w64-mingw32/4.6 respectively
// it needs to be here needed to resolve symbol "___chkstk_ms"
{$linklib gcc}
// The problem ... on i386-win32 these symbols are not resolved
// Error: Undefined symbol: __time32
// Undefined symbol: __localtime32
// Undefined symbol: __gmtime32
// There were 3 errors compiling module, stopping
//
// *BUT*
//
// When I switch to x86_64-win64 everything works fine
// and the test application run perfectly on 64bit windows
{$endif}
// project options set link
// i386-linux version build using make
// i686-ming-w64 and x86_64-ming-w64 build using make configure script
// openssl static libraries. path is set by target information
// $(ProjectDir)/i386-linux, i386-win32, or x86_64-win64
{$linklib libssl.a} // static ssl library
{$linklib libcrypto.a} // static ssl cryptography library
implementation
end.In summary here is what I've done:
I installed mingw-w64
I built versions of openssl using both x86_64-w64-mingw32 and i686-w64-mingw32 successfully.
I copied the resulting libssl.a and libcrypto.a static libraries to my project lib/i386-win32 and lib/x86_64-win64 folders. I setup my environment to refer to /usr/x86_64-w64-mingw32/lib or /usr/i686-w64-mingw32/lib in order to satisy msvcrt, user32 ect I had to copy libgcc.a from /usr/lib/gcc/x86_64-w64-mingw32/4.6 and /usr/lib/gcc/i686-w64-mingw32/4.6
libgcc.a contains "___chkstk_ms" which needs to be resolved. i place a copy of the file in my project lib/i386-win32 and lib/x86_64-win64 folders.
On linux I build for i386-linux and it succeeds. The test application on linux returns the expected results from openssl functions. On linux I build for x86_64-win64 and it succeeds. The test application is copied to my 64bit windows box and returns the expected results from openssl functions.
On linux I build for i386-win32 and it the linker fails when it cannot locale __time32, __localtime32, and __gmtime32.
I have tried searching for:
find . -name "*.a" -exec i686-w64-mingw32-nm -o {} \; | grep -i time32 And I cannot find the functions.
I am at my wits end here. I could really use some help in finding why my pascal compiler needs __time32 when using a static lib built from i686-ming-w64
Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20120515/6e11e485/attachment.html>