Hello Martin, 2012/12/26 Martin Mitáš <[email protected]>: > Dne 26.12.2012 22:01, Ruben Van Boxem napsal(a): >> >> > Is it just for some transitional phase, or the new way from now forever >> > (or until you decide to add yet another DLL depenencies)? >> >> Perhaps I might have forgotten to mention this is an *experimental* >> build. It allows you to use libstdc++'s multithreading capabilities. >> The plan is to add winpthreads to the MinGW-w64 crt, if it will be in >> dll form or not is unknown right now. It is not compulsory to use the >> posix GCC, and won't be in any near future I see. >> > You haven't forgotten to mention the build is experimental but it hasn't > been clear if it is a property of the experimental build only or the > general direction where you go, so thanks for clarification.
Well, in general we won't have POSIX-threading model for Windows-gcc-versions activated by default. As this feature implies that gcc's additional libraries (libgcc, libstdc++, libgfortran, etc) would have dependencies to the posix-threading-library. Later might be acceptable for people playing with C(++)11-features, but for general purpose-usage this isn't suitable. So as Ruben mentioned "experimental" means here "experimental" and not "productive". >> If you're building with GCC you already depend on the libgcc dll, >> unless you link statically, in which case the winpthreads library will >> also be linked statically. > I use only link options -mwindows -municode -mdll, but there is no > dependency on libgcc.dll in my binaries. I always thought the static > linking to libgcc is the default one. I might of course add > -static-libgcc explicitly, that's no issue for me. You will have always dependencies to libgcc within your translated code produced by gcc, due some base routines are provided in that library, which you can't work-a-round that easy. Nevertheless you can avoid to use the shared-variant of gcc's libraries by specifying -static. (and if you don't want it and you aren't using exception-throwing over DLL-boundries in C++, you don't need shared versions). >> > >> > I do not understand why every C application should depend on it even >> > though it does not use posix threads at all (including the C++ <thread> >> > machinery). I strictly play within Win32API boundaries. >> >> The reason lies deep within GCC's internals: the compiler produces >> code which calls internal functions which are implemented in libgcc. >> If GCC is built with posix threads on Windows, libgcc might (there was >> a report that this was true, I don't remember all the details at this >> time, and you could easily check this yourself in the specific case of >> your library) depend on winpthreads. >> > I know gcc team was working on something like that but I always assumed > that it is for the C++11's <thread>, __thead keyword for thread local > storage, all the automagical parallelism language extensions like > AutoMP, (experimental?) optimization passes doing the same and similar > stuff, and that when I stick with "pure old C", compiler should not > generate anything what needs to link against it. Big misunderstanding about meaning of keyword '__thread'. It hasn't to do with C(++)11's thread-class at all. As you mention, it is Thread-Local-Storage-identifier (TLS), and available for all language-standards provided by gcc. Good old C has also got extension (called C11), which implies posix-threading API. So be afraid that standard changes. >> Anyway, the eventual dependency is part of the toolchain, so anyone >> who uses your library should have access to the same compiler anyways. >> > > No. mCtrl is buildable by mingw-w64, mingw-builds as well as MSVC, and > making it buldable in any other toolchain supporting Win32API should be > possible quite fast, probably by just rewriting the MAKEFILE or MSVC > project file. The product (MCTRL.DLL) should be binary compatible > whether you build it in MSVC or by mingw-w64, and I cross-test the > examples from time to time. > > The API of MCTRL.DLL is strictly Win32API-like. It does not depend on > any toolchain-specific types like FILE etc. It is intended to be used by any > compiler which can call STDCALL functions. This includes MSVC, > Embarcadero C++ builder (successor of Borland), mingw(-w64) and its > derivatives, but also other languages (!) like VisualBasic, Python etc. Fine, so you should best not use the "experimental" build of Ruben, and you should keep away from C11/C++11 features. >> I know it's not a win-win. I can't change the reality of things, >> especially the Unix-centricity of the GCC implementation (or that of >> any major open source project). Unfortunately, a decent C++11 >> multithreading implementation will require Windows Vista, and the >> Windows GCC developers have not decided to drop XP compatibility. >> > I do not accuse you for anything. I just search some info to see what > troubles and risks are awaiting me and the project in the future, and > (if they do) what options for solving them are available. Don't be afraid that we will introduce new DLL-depencies. We won't add posix-thread-layer via a DLL into our runtime/startup. Nevertheless we will provide to users ability to use all C11/C++11 features, if they want to use them. But people not using those new features, won't have direct changes in behavior. > Martin Kai ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnmore_122712 _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
