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.
> 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. > > > > 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. > 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. > > 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. Martin ------------------------------------------------------------------------------ Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery and much more. Keep your Java skills current with LearnJavaNow - 200+ hours of step-by-step video tutorials by Java experts. SALE $49.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122612 _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
