Re: [MSVCRT] Cross build fix
On Tue, Jun 01, 2004 at 11:42:28AM +0200, Hans Leidekker wrote:
Hi,
This patch:
http://www.winehq.org/hypermail/wine-cvs/2004/04/0357.html
broke the MinGW build of msvcrt. The changelog says it's a compatibility fix. Dimi: what compatibility were you aiming at with this patch?
Compatibility with other headers. _WCTYPE_T_DEFINED is in a way part of the public interface, and when we use the headers in Winelib apps, we need to define it so we don't end up with duplicate declarations for wint_t/wctype_t. When we build msvcrt it's a different story of course, and we seem to need the exact opposite. Which is why I find the entire MSVCRT() thing not only ugly, but a bit problematic also. Alexandre, why don't we just remove all those MSVCRT() macros, use the headers in Winelib apps, and duplicate what we need with a MSVCRT_ prefix in an internal header that we use just for building? These things are quite stable, so the risk of diverging is small, and for thinks like structures we can write tests to make sure we have the same sizes/layouts. -- Dimi. P.S. Please note that in theory the same situation holds true for all the other sentries. So it's not like we only have a problem with wint_t/wctype_t.
"Dimitrie O. Paun" <dpaun(a)rogers.com> writes:
Alexandre, why don't we just remove all those MSVCRT() macros, use the headers in Winelib apps, and duplicate what we need with a MSVCRT_ prefix in an internal header that we use just for building? These things are quite stable, so the risk of diverging is small, and for thinks like structures we can write tests to make sure we have the same sizes/layouts.
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. -- Alexandre Julliard julliard(a)winehq.org
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. -- Dimi.
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 )
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>
This can work, one problem is that if we go this way, we'll have to 'shadow' all symbols, or else we'll get conflict with the C library. In any event, it's a tricky method that can result in some strange bugs if we don't redefine all symbols, so Alexandre will have to comment on it if we are to try it out. -- Dimi.
"Dimitrie O. Paun" <dpaun(a)rogers.com> writes:
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>
This can work, one problem is that if we go this way, we'll have to 'shadow' all symbols, or else we'll get conflict with the C library. In any event, it's a tricky method that can result in some strange bugs if we don't redefine all symbols, so Alexandre will have to comment on it if we are to try it out.
I don't see how this would solve problems like the _WCTYPE_T_DEFINED issue. -- Alexandre Julliard julliard(a)winehq.org
On Wed, Jun 02, 2004 at 11:09:36AM -0700, Alexandre Julliard wrote:
I don't see how this would solve problems like the _WCTYPE_T_DEFINED issue.
Right, it will not solve problems like this (for Boaz: _WCTYPE_T_DEFINED is a sentry for not defining a type twice, check out pretty much any header under include/msvcrt/ to see how it's used). However, I did grep the source, and it seems that we're using the MSVCRT_ prefix only in dlls/msvcrt/*.c. And so it's not clear to me that duplicating part of the headers is going to be that bad. I mean, we will need duplication only for the stuff that we use internally across files. That doesn't include math functions for example, and a bunch of other stuff. If you're positive this is not a good idea, I'll drop it, but if there is a chance it would be acceptable, I might give it a try... -- Dimi.
"Dimitrie O. Paun" <dpaun(a)rogers.com> writes:
However, I did grep the source, and it seems that we're using the MSVCRT_ prefix only in dlls/msvcrt/*.c. And so it's not clear to me that duplicating part of the headers is going to be that bad. I mean, we will need duplication only for the stuff that we use internally across files. That doesn't include math functions for example, and a bunch of other stuff.
If you're positive this is not a good idea, I'll drop it, but if there is a chance it would be acceptable, I might give it a try...
It can be acceptable, but it will require writing regression tests to ensure that the definitions remain in sync. -- Alexandre Julliard julliard(a)winehq.org
participants (3)
-
Alexandre Julliard -
Boaz Harrosh -
Dimitrie O. Paun