Segmentation fault after new wine update and install

Shachar Shemesh wine-devel at shemesh.biz
Wed Sep 10 13:14:47 CDT 2003


Vincent Béron wrote:

>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?
>  
>
Probably should be "static inline". That's the way you usually do it 
inside headers.

I was under the impression that InterlockedCompareExchange rightfully 
belonged in kernel32 (that's where nm said it was defined, after all). 
That's why I thought this was a circular dependancy.

Ahh, I now see why I thought so. It is also defined in 
dlls/kernel/sync.c as a regular function.
MSDN says this:

*Client: *Included in Windows XP, Windows 2000 Professional, Windows NT 
Workstation 4.0, Windows Me, and Windows 98.
*Server: *Included in Windows Server 2003, Windows 2000 Server, and 
Windows NT Server 4.0.
*Header: *Declared in Winbase.h; include Windows.h.
*Library: *Use Kernel32.lib.

I think it's probably a bad idea to use this function (actually, 
InterlockedCompareExchangePointer) from ntdll at all. This is a circular 
dependancy, even if we manage to get away with it using optimizer tricks.

>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.
>  
>
You did the wrong test
the question is not whether ntdll.dll depends on kernel32 (if you 
compile without optimizations, it has an undefined symbol, but nm is the 
tool to show you that, not ldd). The question was whether wine depended 
on ntdll.
sun at sun:~/sources/wine/wine$ ldd miscemu/wine
        libntdll.dll.so => 
/home/sun/sources/wine/wine/dlls/libntdll.dll.so (0x40015000)
        libwine.so.1 => not found
        libwine_unicode.so.1 => not found
        libc.so.6 => /lib/libc.so.6 (0x40101000)
        libwine.so.1 => not found
        libwine_unicode.so.1 => not found
        libm.so.6 => /lib/libm.so.6 (0x40226000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

>>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
>  
>
While I think the the "-lntdll" is a strange kludge in miscemu/wine 
makefile, and therefor should go if it's indeed not necessary, I don't 
think it is correct to load kernel32 before ntdll. The DLLs obviously 
depend one on the other in the opposite order (or, more precisely, should).

             Shachar

-- 
Shachar Shemesh
Open Source integration consultant
Home page & resume - http://www.shemesh.biz/





More information about the wine-devel mailing list