strcasecmp

[David Fraser]

Dimitrie O. Paun wrote:

>On December 19, 2002 09:26 am, Waldek Hebisch wrote:
>  
>
>>If we are going to seriously support mingw then we need "mingw headers".
>>I am not sure if true mingw headres are different enuugh from normal
>>wine and msvcrt headers to warrant extra subdirectory, but logically
>>they form a separate set. I suggest to put conditionls (if needed) in
>>msvcrt headers corresponding to mingw headers, and make a separate
>>subdirectory for mingw headers which emulate Unix headers.
>>    
>>
>
>Right. I haven't looked at the mingw headers, but I assume they are
>rather similar to the ones in glibc. If that's the case, we can
>reuse those (if you have gcc which you have to anyway if you want to
>use the mingwrap stuff):
>
>[dimi at dimi wine.src]$ sed -n 290,296p /usr/lib/gcc-lib/i386-redhat-linux/3.2/include/stddef.h
>#ifndef __WCHAR_TYPE__
>#define __WCHAR_TYPE__ int
>#endif
>#ifndef __cplusplus
>typedef __WCHAR_TYPE__ wchar_t;
>#endif
>#endif
>
>Which means we can simply -D__WCHAR_TYPE__=unsigned\ short
>
>But we still can not link. For that, we need to reimplement all wchar_t
>using functions, and link those in before the glibc ones. Linking tricks
>are not my strenght, anyone know how we can do that? Does it work to
>just place a lib with those symbols first in the -l list?
>
>  
>
Not sure exactly what you're looking for here - but I think you're 
wanting to know
about the way it resolves symbols.
Basically symbol lookups are only done in libraries that appear later on 
the command line than
the one needing the symbol. So if libb.a depends on liba.a, then
gcc bladibla -lb -la
will work while
gcc bladibla -la -lb
will fail.

Hope that's relevant
David