I'm not the only one who had the issue but no one had posted a solution to it. Any help would be appreciated. Thanks in advance!
Solo Ace - Sun Jun 05, 2005 4:40 pm
Post subject:
Well, according to the reply posted to this question it's not possible to use MinGW to compile it so you'll have to use VC++.
Anyway, let's read some man pages.
Code: Show/Hide --enable-auto-import
Do sophisticated linking of "_symbol" to "__imp__symbol" for DATA imports from DLLs, and create the necessary thunking symbols when building the import libraries with those DATA exports. Note: Use of the 'auto-import' extension will cause the text section of the image file to be made writable. This does not conform to the PE- COFF format specification published by Microsoft. Using 'auto-import' generally will 'just work' -- but sometimes you may see this message: "variable '<var>' can't be auto-imported. Please read the documen- tation for ld's "--enable-auto-import" for details." This message occurs when some (sub)expression accesses an address ultimately given by the sum of two constants (Win32 import tables only allow one). Instances where this may occur include accesses to member fields of struct variables imported from a DLL, as well as using a constant index into an array variable imported from a DLL. Any multiword variable (arrays, structs, long long, etc) may trigger this error condition. However, regardless of the exact data type of the offending exported variable, ld will always detect it, issue the warning, and exit. There are several ways to address this difficulty, regardless of the data type of the exported variable: One way is to use --enable-runtime-pseudo-reloc switch. This leaves the task of adjusting references in your client code for runtime environment, so this method works only when runtime environment supports this feature. A second solution is to force one of the 'constants' to be a vari- able -- that is, unknown and un-optimizable at compile time. For arrays, there are two possibilities: a) make the indexee (the array's address) a variable, or b) make the 'constant' index a variable. Thus: extern type extern_array[]; extern_array[1] --> { volatile type *t=extern_array; t[1] } or extern type extern_array[]; extern_array[1] --> { volatile int t=1; extern_array[t] } For structs (and most other multiword data types) the only option is to make the struct itself (or the long long, or the ...) vari- able: extern struct s extern_struct; extern_struct.field --> { volatile struct s *t=&extern_struct; t->field } or extern long long extern_ll; extern_ll --> { volatile long long * local_ll=&extern_ll; *local_ll } A third method of dealing with this difficulty is to abandon 'auto-import' for the offending symbol and mark it with "__declspec(dllimport)". However, in practise that requires using compile-time #defines to indicate whether you are building a DLL, building client code that will link to the DLL, or merely build- ing/linking to a static library. In making the choice between the various methods of resolving the 'direct address with constant off- set' problem, you should consider typical real-world usage: Original: --foo.h extern int arr[]; --foo.c #include "foo.h" void main(int argc, char **argv){ printf("%d\n",arr[1]); } Solution 1: --foo.h extern int arr[]; --foo.c #include "foo.h" void main(int argc, char **argv){ /* This workaround is for win32 and cygwin; do not "optimize" */ volatile int *parr = arr; printf("%d\n",parr[1]); } Solution 2: --foo.h /* Note: auto-export is assumed (no __declspec(dllexport)) */ #if (defined(_WIN32) || defined(__CYGWIN__)) && \ !(defined(FOO_BUILD_DLL) || defined(FOO_STATIC)) #define FOO_IMPORT __declspec(dllimport) #else #define FOO_IMPORT #endif extern FOO_IMPORT int arr[]; --foo.c #include "foo.h" void main(int argc, char **argv){ printf("%d\n",arr[1]); } A fourth way to avoid this problem is to re-code your library to use a functional interface rather than a data interface for the offending variables (e.g. set_foo() and get_foo() accessor func- tions). [This option is specific to the i386 PE targeted port of the linker] |
Does that help anything?
CypherJF - Sun Jun 05, 2005 5:08 pm
Post subject:
I wonder why there is no such notice on the MySQL tech pages under their note of what you need to pass to the compiler to compile w/ Win32. Not to be able to compile w/o MS' compiler, just sucks. :/
Like okay I could compile w/ VC++ 6.0 but I hear its probably one of the worse compilers out there. I do have VS .NET 2002 academic - but it can't run well on my machine - i do know MS released free compilers for C++ but being stuck on 56k I'm not going to download 300+ MB.
So, I guess I am stuck w/ using the MSC++ 6.0 compiler. :/ *gr* Any suggestions?
50% Packetloss - Sun Jun 05, 2005 6:11 pm
Post subject:
It is a good compiler. I have never had a problem with it. The free VC++ toolkit comes with everything you need.
Maybe this page will help you with mingw
http://www.synnottsoftware.com/tutorials/mysqlwindows.php
CypherJF - Sun Jun 05, 2005 8:41 pm
Post subject:
thanks guys - i'm downloading the 80MB of VC++ 2005 Express Edition...