Hi, This is one of the last remaining hacks needed to compile the d3d parts of Wine with Visual Studio. Our definition of **environ is conflicting with one already in the Windows SDK headers:
1>....\wine\libs\wine\loader.c(54): warning C4273: '_environ': Inkonsistente DLL-Bindung. 1> C:\Program Files\Microsoft Visual Studio 10.0\VC\include\stdlib.h(299): Siehe vorherige Definition von '_environ'
I'm sorry for the German, I don't know how to change this. Google finds only other clueless people. Either way it says something like "Inconsistent DLL binding"
The line in stdlib.h declares _environ as
_CRTIMP extern char ** _environ; /* pointer to environment table */
The compiler just writes a warning, but afterwards linking fails:
1>loader.obj : error LNK2001: Nicht aufgelöstes externes Symbol "__environ".
The linker complains about an "unresolved external symbol __environ". Removing our declaration of environ fixes the warning, link error and libwine seems to work OK.
I don't know what the proper fix is, please advise. Maybe this code shouldn't be compiled at all? I don't think I need the loader code on Windows.
Stefan
On 25.05.2011 22:52, Stefan Dösinger wrote:
I'm sorry for the German, I don't know how to change this. Google finds only other clueless people. Either way it says something like "Inconsistent DLL binding"
I believe the English translation is “inconsistent DLL linkage”.
The line in stdlib.h declares _environ as
_CRTIMP extern char ** _environ; /* pointer to environment table */
The compiler just writes a warning, but afterwards linking fails:
1>loader.obj : error LNK2001: Nicht aufgelöstes externes Symbol "__environ".
The linker complains about an "unresolved external symbol __environ". Removing our declaration of environ fixes the warning, link error and libwine seems to work OK.
I don't know what the proper fix is, please advise. Maybe this code shouldn't be compiled at all? I don't think I need the loader code on Windows.
The underlying issue is probably the _CRTIMP - that's most likely _declspec(dllimport) in MSVC. This matters, as DLL-imported and “plain” extern variables are handled differently on Windows. IIRC DLL export/import of variables is indirect - when DLL-importing a variable you really import a _pointer_ to the variable. So accessing the variable dereferences some pointer. “extern” variables, otoh, are accessed directly (resolving the actual variable location is handled at link-time).
-f.r.
On Wednesday 25 May 2011 23:04:02 Frank Richter wrote:
The underlying issue is probably the _CRTIMP - that's most likely _declspec(dllimport) in MSVC.
I suspected something like this, but msvc didn't want to tell me what _CRTIMP was. Either way it doesn't get me much closer to a fix.
-
Frank Richter -
Stefan Dösinger