[MSVCRT] Cross build fix

[Boaz Harrosh]

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 )