> 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.
Ah, so it's a load-time dynamic linking operation in which the i386 PE linker embeds info (into the final dll/exe) that windows uses to locate the correct msvcr???.dll, correct? If yes, shouldn't the msvcr???.dll name referenced by the object-file symbols be in the archive so that the PE linker knows what info to embed into the final object? For example, I see the following in libmoldname.a via `strings`: C:\DevKit-4.7.2\mingw\i686-w64-mingw32\lib>strings libmoldname.a | grep -B 10 -A 3 msvcr lib32_libmoldname_a-strcasecmp.o/ lib32_libmoldname_a-strncasecmp.o/ lib32_libmoldname_a-wcscmpi.o/ dmket.o/ 1348512452 1000 1000 100644 582 ` .text 0`.data .bss .idata$4 .idata$5 .idata$7 => msvcrt.dll .file fake .text Hmm, `objdump` must not be able to extract this info from the archive. Probably need to find/write a little PE dumper to walk the archive. That said, is the only way to ensure the link uses msvcr90.dll and not msvcrt.dll is to do the following? 1) use `-static` since the gcc runtime dll's in rubenvb and mingwbuilds link to msvcrt.dll 2) tweak `*cpp` spec entry to add `-D__MSVCRT_VERSION__=0x0900` 3) tweak the `*libgcc:` spec entry to (a) remove `-lmoldname`, and (b) replace `-lmsvcrt` with `-lmsvcr90` As always, very helpful Kai. Thank you (and Ernie) for your time and detailed feedback. Jon --- Fail fast. Fail often. Fail publicly. Learn. Adapt. Repeat. http://thecodeshop.github.com | http://jonforums.github.com/ twitter: @jonforums ------------------------------------------------------------------------------ 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
