davidf at sjsoft.com
Fri Dec 20 00:06:12 CST 2002
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
>#define __WCHAR_TYPE__ int
>typedef __WCHAR_TYPE__ wchar_t;
>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
Hope that's relevant
More information about the wine-devel