Le mer 10/09/2003 à 11:51, Shachar Shemesh a écrit :
That's exactly the problem I'm having with compiling Wine without optimizations. the wine binary tries to link with ntdll. ntdll needs "InterlockedCompareExchange" from kernel32. In my case, this translates to a compilation error, which I have not managed to eliminate.
I'm leaning towards the inline InterlockedCompareExchange from winbase.h, as if I rebuild ntdll with -O1 miscemu/wine is built correctly (ie ntdll doesn't have any undefined references). It's from win32/device.c and win32/except.c which call InterlockedCompareExchangePointer(), which itself calls InterlockedCompareExchange() from winbase.h.
"extern inline InterlockedCompareExchange() {return bar();}" seems a bit odd for a function definition. What the purpose of having both extern and inline?
The whole point might be moot regarding linking, as ntdll is not required for miscemu/wine (see below).
Ok, the tie breaker is in. On Windows 2000, ntdll.dll is not depnding on ANYTHING else. On the other hand, kernel32.dll does depend on ntdll.dll. This means that we have a circular dependancy in Wine that is not there in Windows 2000.
Would it be acceptable to swap the following 2 lines in wine_init (sorry about the wrapping): if (!(ntdll = dlopen_dll( "ntdll.dll", error, error_size, 0, &file_exists ))) return; if (!dlopen_dll( "kernel32.dll", error, error_size, 0, &file_exists )) return;
I think it would be wrong. Kernel32 obviously does depend on ntdll. It would probably be better to figure out why ntdll depends on kernel32 (we know that - InterlockedCompareExchange), and remove that.
See above. BTW, ldd ntdll.dll.so doesn't show kernel32.
so kernel32.dll is opened before ntdll.dll, or is there a dependency from kernel32.dll to ntdll.dll?
Unfortunetly, there is in Wine too.
Yes, ntdll is the first thing to be loaded.
Or is it possible to move the pthread_init function elsewhere, to someplace called before ntdll.dll is loaded?
Do "ldd miscemu/wine" for an answer - ntdll is loaded by the Linux linker, even if dlopen was not called at all. It's an interesting question why we need the dlopen, then.
Hmmm... I guess the -lntdll.dll on the linking line of miscemu/wine is the cause :) I've been able to link it while removing that part, so I'm not sure if that part is still useful.
Vincent