[MSVCRT] Cross build fix
boaz at hishome.net
Wed Jun 2 02:58:25 CDT 2004
Dimitrie O. Paun wrote:
>On Tue, Jun 01, 2004 at 11:16:06AM -0700, Alexandre Julliard wrote:
>>No I don't think we want that. The headers are not that stable, we are
>>still making changes to them. We also need the MSVCRT definitions in
>>multiple dlls so there would be a lot of duplication.
>Yes, the headers are not stable, but the interface is. The probability
>of one of those functions to change signature is virtually none.
>And we don't need all the headers, just some functions and structures.
>It just seems to me we have way too many constraints to be able to do
>a decent job. We're already cutting corners on the MSVC compatibility
>because of this mixing.
When compiling with STLPort I saw a method that can eliminate the need
for the MSVCRT macro and yet produce MSVCRT_xxx for those who need it
and an xxx for those how don't.
Basically you have your Regular cleanroom headers-set for wine-lib and
external dlls. And you have another set of headers for msvcrt
compilation. In The second set:
- each header does some magic like #define stat_t MSVCRT_stat_t
- than #include <original/header.h>
Now compilation units that need the MSVCRT_xxx use an extra -I
"$wine_include/internal_msvcrt" switch in the make files.
should I random pick an header and demonstrate the Technique?
From what I understand, the need for these differences are so the
msvcrt.dll.so could define it's own set of functions and in place use
gcc-glibc for implementation. This way stirring a way from both
duplicates in Linking and conflicts with gcc-glibc headers.
[Q] Why don't we avoid glibc all together. Take what ever code we are
missing and have a complete self contained implementation?
Just like MinGW's -nocygwin
(Now if we where using C++ the problems would be solved in 2 seconds
flat: "namespace". Was not "namespace" back ported to C )
More information about the wine-devel