On Wed, 18 Dec 2002, Dimitrie O. Paun wrote:
We don't have a _strcasecmp in msvcrt, but wew do have a _stricmp, which seems to be doing the same thing.
ChangeLog Map strcasecmp to _stricmp.
Actually I don't see strcasecmp defined anywhere on Windows, which is a bit strange. Should we remove it? Which application uses it?
On December 18, 2002 03:29 pm, Francois Gouget wrote:
Actually I don't see strcasecmp defined anywhere on Windows, which is a bit strange. Should we remove it? Which application uses it?
wxWindows.
On Wed, 18 Dec 2002, Dimitrie O. Paun wrote:
On December 18, 2002 03:29 pm, Francois Gouget wrote:
Actually I don't see strcasecmp defined anywhere on Windows, which is a bit strange. Should we remove it? Which application uses it?
wxWindows.
Does it compile with Visual C++? I guess not if it's using strcasecmp. But the msvcrt headers are Visual C++ headers so I'm not sure they should contain stuff like strcasecmp.
"Dimitrie" == Dimitrie O Paun dpaun@rogers.com writes:
Dimitrie> On December 18, 2002 03:29 pm, Francois Gouget wrote: >> Actually I don't see strcasecmp defined anywhere on Windows, which is >> a bit strange. Should we remove it? Which application uses it?
Dimitrie> wxWindows.
Are you sure that wxWindows doesn't do a
#ifdef __WIN__ #define strcasecmp stricmp #endif
somewhere?
Bye
On Wed, 18 Dec 2002, Uwe Bonnes wrote: [...]
Are you sure that wxWindows doesn't do a
#ifdef __WIN__ #define strcasecmp stricmp #endif
somewhere?
I sort of suspect something like this. And then the big question is why don't we get this #define when compiling with Wine?
There is the same issue gethostname(). Visual C++ does not define it in the msvcrt headers so how does one compile wxWindows with visual C++?
On December 18, 2002 05:06 pm, Francois Gouget wrote:
There is the same issue gethostname(). Visual C++ does not define it in the msvcrt headers so how does one compile wxWindows with visual C++?
Because these are apps that compile under MinGW using their headers for libc, not the crtdll/msvcrt ones.
In theory, we should compile such apps using the native libc headers, but that does not work. And it does not work because of -fwchar-short, which is a must...
So we are in a bit of a bind: we _have_ to use msvcrt, but the app expects functions that are present only in the Unix/MinGW headers. What do we do?
On December 18, 2002 05:06 pm, Francois Gouget wrote:
There is the same issue gethostname(). Visual C++ does not define it in the msvcrt headers so how does one compile wxWindows with visual C++?
Because these are apps that compile under MinGW using their headers for libc, not the crtdll/msvcrt ones.
In theory, we should compile such apps using the native libc headers, but that does not work. And it does not work because of -fwchar-short, which is a must...
So we are in a bit of a bind: we _have_ to use msvcrt, but the app expects functions that are present only in the Unix/MinGW headers. What do we do?
-- Dimi.
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.
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?
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
-
David Fraser -
Dimitrie O. Paun -
Francois Gouget -
Uwe Bonnes -
Waldek Hebisch