Helle Simson, this list seems to me more like good content to our FAQ-section in Wiki. Some of those points might be defining general goals we wanna to define, or decline for mingw-w64 in general. Most of those points are looking like something desirable, but on a technical POV it shows that some of those points aren't implementable due missing definitions in specification, simple vendor differences, and misunderstandings in general goals. I will try to give brief answers to your questions, and maybe somebody thinks it is worth to add those answers to FAQ in our Wiki.
2012/10/25 Simson Garfinkel <sims...@acm.org>: > I've been on this mailing list for some time now and use mingw (both the > 32-bit and 64-bit versions) for several production systems. What I would like > to see is not a commitment to a release schedule but a document that clearly > states the commitment to specific principles. For example: > > * Can compile the same source code as MSC VC++ (is this true?) As long as source doesn't use vendor-specific extension, this is possible. We invested some efforts to add new features to gcc/g++ to implement some compliant-features (eg x64 SEH exception in 4.8, push_macro/pop_macro pragma, __int128, etc) which are vendor specific VC extensions. Also there were recently spend some efforts for g++ to make call-ABI in class-member functions more compatible to that what MS defines by its 32-bit ABI. Additionally we provide tools - like gendef, genidl, widl, genpe, etc - which are trying to fill some gaps in standard-toolchain. Nevertheless we won't be able to make both compilers feature-identical and this can't be a serious goal as official documentation and papers about those features aren't available for us. > * No Microsoft copyrighted headers in the build tree (so reimplementation) Sure, this is a primary goal for us. This doesn't mean that user can't use for her/him-self additional SDKs provided by MS within our toolchain. As far as I learned are some user using for example the DIA SDK successful. > * Uses Microsoft DLLs, rather than GNU DLLs, for key functions (is this true > anymore?) For platform-functions we have to use OS provided DLLs, which are of course provided by MS. For C-runtime we are using by default the msvcrt.dll - this is a big subject and might need additional comments as there are huge version-differences present - version. But of course it is possible to build applications using different MS runtimes, like msvcr100.dll, msvcr80.dll, etc. We don't use those DLLs by default, as they aren't part of the standard-OS DLL set. There are additional DLLs - and were ever for gcc/g++ based toolchains - which are provided by the toolchain. Typical libraries provided by gcc are libgcc, libgfortran, libstdc++, libquadmath, libssp. Those DLLs can be used, but you have then of course to redistribute them to end-user for running your build app. A way to avoid this is to use static version of those libraries. This avoids dependencies to none-system DLLs in general - see -static options. If you plan to use a different runtime DLL, you might be in need to rebuild those gcc-target libraries, as they are build by most pre-compiled toolchains only using msvcrt.dll (Side note that static versions of gcc's libraries don't need to be rebuild here). > * Compiles both Windows Threads and POSIX threads (true?) Yes, that true if you are using a pthread library. There is pthreads-win32 venture, or you can use winpthread - a mingw-w64 owned sub-project - for this. By using winpthread you are able to build gcc's target-libraries in POSIX-way. > * Equally produces static-linked and dynamic-linked binaries (this is VITAL > for incident response. The problem is that many of the packets in the > repositories include dynamic versions but not static versions) Sure, dynamic and static libraries are provided. The issue about static-version is in some cases the used license for them. For gcc's runtime-libraries there aren't any issues, as there is a runtime-exception present, but for other libraries there might be problems inflicted by license. Eg (L)GPL's viral effect on license. > * Compiled code supports both gdb and Microsoft debugger tools (true?) Well, that is technical not really possible, as gdb doesn't supports pdb-format (not offical documented as most of MS' debugging stuff), and windbg doesn't supports dwarf-2 debugging information. You should be able to debug with both debuggers any application, but you won't be able to see further debugging-info. Regards, Kai ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
