On 10/26/2012 02:19, Kai Tietz wrote: > 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 >> 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. >
Yes, this is a valid goal 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. > Yes, MSDN comes into play a lot here. >> * 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). > Microsoft DLLs when possible, eg msvcrt.dll, though it is not possible unless you stick strictly to C. Like Kai says, C++ support comes from GCC libstdc++, fortran support from libgfortran etc. You should have no legal problems distributing these DLLs with your programs in anyway. >> * 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. > Kai means the openMP implementation, yes you still can choose between win32 threads and Posix threads in your applications if you use them directly, though it is not a good idea to mix them. >> * 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. > I think this is more of a buildsystem issue rather than something mingw-w64 specific. Look at autotools and libtool, they handle shared libraries and DLLs fine, for most parts. >> * 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. Like Kai says, gdb can't understand MS debug format, neither can MS tools understand GNU debug format. It's a long long way to understand MS debug format due to lack of documentation, but it won't stop you from using a debugger from MS if you don't mind looking at the assembly level instructions.
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
