develooper Front page | perl.perl5.porters | Postings from December 2008

RE: [perl #61492] ExtUtils::MM_Win32 should not generate "mt" command when CRT is statically linked

Thread Previous | Thread Next
From:
Jan Dubois
Date:
December 19, 2008 03:02
Subject:
RE: [perl #61492] ExtUtils::MM_Win32 should not generate "mt" command when CRT is statically linked
Message ID:
00f901c961c9$5321e1e0$f965a5a0$@com
On Fri, 19 Dec 2008, Steve Hay wrote:
> Erland Sommarskog (via RT) wrote:
> > ExtUtils::MM_Win32 includes these lines:
> >
> >       # VS2005 (aka VC 8) or higher, but not for 64-bit compiler from
> >       Platform SDK if ($Config{ivsize} == 4 && $Config{cc} eq 'cl'
> >     and $Config{ccversion} =~ /^(\d+)/ and $1 >= 14) {
> >         push(@m,
> >           q{
> >    mt -nologo -manifest $@.manifest -outputresource:$@;2 && del
> >       $@.manifest}); }
> >
> > I am told the that "mt" command is there, because VC8 and later
> > generates a manifest file that is needed to use the MSVCRT80.DLL or
> > corresponding file.
> >
> > However, if you opt to link statically to the CRT and thus
> > include the CRT routines in your own DLL, VC80 will not generate
> > any manifest file, and the "mt" command and thus the entire build
> > will fail.
> >
> > Note that there are several options to request static linkage:
> > /MT,/MTd and a couple more.

I don't think it is feasible to detect static vs. dynamic linking by analyzing
all the compile and link options.  It would be much easier to only invoke the
`mt` command if the compile step actually generated a manifest:

    if exist $@.manifest mt -nologo -manifest $@.manifest ...
    if exist $@.manifest del $@.manifest

[...]

> I'm not even sure I understand how you've told EU::MM to static-link the
> CRT. I thought if you're using EU::MM to build anything then it just
> automatically uses the perl build options. Can we see a sample Makefile
> that exhibits the problem?

He is just adding '/MT' to CCFLAGS in WriteMakeFile().

> I'm also always slightly uneasy about mix'n'match-ing different CRTs. If
> one component (exe/dll) is built using MSVCR*.dll, then I'd always
> prefer all the other components to do likewise, rather than having some
> others built with LIBC.lib or whatever.

Yes, it is preferable to use just a single CRT, but mixing them generally
works as long as you are careful not to pass FILE* pointers to a different
CRT than the one that created it, and not to free() memory via a CRT that
didn't malloc() it etc.  There also used to be problems with C++ structured
exception handling, but those don't matter if you just use plain C.

> Is it possible for you to build everything with -MD, like EU::MM is
> expecting anyway?

He is getting linking problems without /MT and is not interested in
figuring out how to solve them.

I think the change I suggested above should be safe enough to apply,
even if you personally don't want to mix and match CRTs yourself.

Cheers,
-Jan


Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About