Dimitrie O. Paun wrote:
On December 19, 2002 09:26 am, Waldek Hebisch wrote:Not sure exactly what you're looking for here - but I think you're wanting to know
If we are going to seriously support mingw then we need "mingw headers".Right. I haven't looked at the mingw headers, but I assume they are
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.
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?
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
