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@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