From: Tor L. <tm...@ik...> - 2000-11-09 07:08:44
|
> I seem to remember one time, some while ago, when I did a > comparison of the gcc output executable and an msvc output > executable...they did not match. Well, you wouldn't really expect two compilers to produce identical code, would you? > > > It is a good thing to be able to interface with the msvc > > > compiled code, but it should not be set as part of the default > > > specs for gcc/++, not by any means. I disagree here. (And let's keep C++ out of this discussion, interoperability between C++ code compiled by different compilers is mostly impossible anyway.) To get back to another question discussed some time ago, "What *is* MinGW"... www.mingw.org says: "MinGW is a collection of header files and import libraries that allow one to use GCC and produce native Windows32 programs that do not rely on any 3rd-party DLLs." To me, this clearly indicates that the term "mingw" names a *build* environment only. The *target* environment is Win32, and its msvcrt or crtdll C runtimes. There is no mingw runtime environment. (Oh well, there is a libmingw32.a, but I don't think one should think of that as a runtime environment, it's mostly compiler-specific startup code. Except for the dirent functions, which I BTW think shouldn't be there, but in a separate DLL, so that it would be a generic dirent implementation, also usable from MSVC-compiled code.) Thus IMHO talking about "ports to Mingw32" is a bit misleading. But if it is understood to mean "ports to the mingw32 build environment" it's OK. But really, how many people are interested in rebuilding some common library themselves, if it is available ready-built? Anyway, I think that mingwrep should really more profile itself as a repository for canonical Windows ports of common Open Source libraries, and make the libraries usable by MSVC users, too. (One could see this as a way to lure MSVC users into the Open Source mindset...) In addition to compiling with -fnative-struct, this means providing import libraries in .lib format, too. (The freely (as in $0.00) available PlatformSDK includes tools to produce them.) (No, I don't think that mingwrep needs to provide nmake makefiles or, shock horror, MSVC workspaces or whatever they are called.) > Finally, if someone really understands what -fnative-struct > switch does, then they are probably very capable of opening > their favorite editor and modifying their own spec file > accordingly. What spec file? If your average point-and-click MSVC developer is looking for a ready-built Windows port of <insert favourite open source library here>, do we want her to think "Oh great, this nifty library is available here. But oh no, these open source guys on purpose have made it not binary compatible with my compiler. They are just like Microsoft. I guess I'll just have to spend a week building it myself then, or buy it from some commercial redistributor"? Anyway, this whole -fnative-struct question might not be relevant for most libraries except gtk... Does anybody have a guess how many libraries in their API use the kinds of structs that are allocated differently with -fnative-struct? --tml |