Hi Jon, 2013/3/2 Jon <[email protected]>: >> > There is one problem: There is no liboldname90 in Mingw-w64, hence I kept >> > liboldname. >> Yes, for what purpose you need it? > > I'm updating my 32/64bit build systems to better automate how I use > mingw/mingw-w64, and have three followup questions: > > 1) Why do mingw-w64 based toolchains (rubenvb, mingwbuilds) only provide > `libmoldname.a` (objects linked to msvcrt, yes?) but mingw toolchains provide > `libmoldname{70,71,80,90,100}[d].a`?
Well, default library we support is msvcrt.dll one. So we just taken care about moldname for it. In general it is better to add those alias to the default import-library. Having here an additional library looks to me awkward. It adds a dependency to a none-standard library without a good need. > 2) If one needs symbols from `libmoldname.a` and needs to link against a CRT > different than msvcrt.dll, what's the best way to resolve? For the majority > of use cases I expect libmoldname isn't needed so one can kill it in a custom > spec file, but I am curious as to "The mingw-w64 Way" Best way is to make moldname obsolete at all and add those aliases provided by libmoldname(???).a directly within msvcr???-import library. See for this the '==' command of .def file syntax. > 3) My objdump/nm fu is weaker than my curiousity...what's the easiest way to > discover the msvcrt version used by the objects in libraries like > `libmoldname.a`? In objects you won't have any chance to detect that. An object-file references symbols, which might be only present within specific version of msvcr???.dll-version, but you can't actual see that directly. An object (as a static library) isn't finally linked and therefore not strictly bound to one specific runtime-version. > Jon > Hope this answers your questions, 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_d2d_feb _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
