On Sat, Mar 2, 2013 at 1:15 PM, Jon wrote:
>> > 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`?
>
> 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"
>
> 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`?
My opinion is that libmoldname is a bastard child set up to promote
the use of MinGW in the beginning. It was created because many of the
common POSIX symbols were prefixed with _ by MS so rather than forcing
a conversion for something already provided just map the POSIX
expecting symbol to the NON-ANSI _ prefixed symbol already provided.
Can you do without it? Maybe. To check define _NO_OLDNAME before
during compile. But your program will need to use the _ prefixed
symbol instead of the POSIX similar one. I do not know why MOLDNAME
was chosen as the library name, it sounds a bit over stated for the
purpose it provides.
--
Earnie
-- https://sites.google.com/site/earnieboyd
------------------------------------------------------------------------------
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
