Re: [Mingw-users] Linking against MSVCR71.DLL

[Brian Dessent <brian@xxxxxxxxxxx>]

wilson1442@xxxxxxxxxxxxx wrote:

> > The problem is libmoldname. As you might know, the MS runtime spells
> > stat as _stat and so on. ...
> 
> I noticed Microsoft seem overly fond of '_'.  In fact, some poking
> around with nm seems to reveal that sometimes they prepend *two* of them
> just to keep you on your toes.  IThinkTheyPreferReallyLongIDs, and
> throwing in an underscore is their way of subverting short,
> easy-to-remember ones.

All symbols on the PE platform have a leading underscore added to their
assembler names.  When you write foo() in a C program the actual name of
the function is _foo at the assembler level.  This is a very common
thing, and I believe you will find it on many old Unix/BSD platforms as
well.  Linux removed the leading underscore when they switched from
a.out to ELF back in the olden times, if I recall correctly.  Anyway, my
point is simply that a leading underscore is normal and common.

What MS did with the C-level-visible underscores was to add an
additional one to every function that wasn't part of C89/ANSI, to keep
the namespace clean.  It was probably one of those decisions made back
in ancient times when they were selling a 16 bit compiler, but once MS
does something they are forever doomed to keep doing it the same way
until the end of time, it seems.

> > But libmoldname ...
> 
> I saw "-lmoldname", and wondered what it was.  I try to keep the mold in
> my programs to a minimum.

Just FYI, the m stands for MSVCRT, as there are two flavors of the
runtime, CRTDLL and MSVCRT.  There is also a libcoldname, and so on. 
I'm not aware of anybody who uses CRTDLL or if it even still works, but
there it is.

Greg Chicares wrote:

> See the "we believe they form a single program" section here:
> 
> http://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins
> 
> as well as this:
> 
> http://www.gnu.org/licenses/gpl-faq.html#WindowsRuntimeAndGPL
> 
> My guess is that they'd view it as a sham. And the likely
> issue with the ms license, mentioned earlier in this thread,
> would still remain.

So it seems two things are clear: if you own a license to MSVC++ and use
it to build your code, you are allowed (and obligated) to distribute the
runtime with your programs; and if you use MSVC++ to build your GPL code
it is not a violation of the GPL since the runtime is part of the
tooling.

What isn't clear is what happens if you use non-MS tools to link your
code with that same runtime.  To make matters more complicated, MS
offers free downloads of the VC runtime files on their Microsoft
Downloads area.  So one potential workaround would be to distribute your
program and have the installer point them to that link if it detects the
runtime is not present.  That's not a very user-friendly way of handling
it, but it at least resolves the issue of distribution.

The linking issue is still problemmatic -- the question becomes what
does the FSF say about using Free software to link against that same
runtime, rather than using the MS tools.

Brian

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
MinGW-users mailing list
MinGW-users@xxxxxxxxxxxxxxxxxxxxx

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users