Libraries for MSVC++

[David Oswald]

Currently Inline is choosing the following defaults for MSVC++:

elsif ( $Config{osname} =~ m/^MSWin/ ) {
$cc_guess = 'cl -TP -EHsc';
$libs_guess = ' MSVCIRT.LIB ';
}

However, the docs I found here: http://support.microsoft.com/kb/154753

...suggest that library pertains to the old style iostream.h headers,
and that there are other options for the newer iostream headers.

I have a PASS test case here:
http://www.cpantesters.org/cpan/report/6c31c478-0eee-1019-8efa-b89a05085451
...where we're fortunate enough that the smoke tester had
ExtUtils::CppGuess installed (in which case one of my optional tests
runs), and that gave me additional info.

# Detected MSWin (probably ActiveState).
#
# Compiler guesses:
# EU::CppGuess: [cl -TP -EHsc ],
# Makefile.PL: [cl -TP -EHsc].
# Linker guesses:
# EU::CppGuess: [ msvcprt.lib ],
# Makefile.PL: [MSVCIRT.LIB].
t/08cppguess.t ......... ok

So EU::CppGuess is recommending msvcprt.lib. That library seems to
pertain to a debug compile. There are other options for single and
multi-threaded non-debug environments.

Does anyone have any input on what (if any) changes we should be
making here? I'm thinking the logic needs additional complexity to
determine if we've got a debug build of Perl, and if we're in a single
or multi-threaded environment. Although nobody seems to have
complained yet, and I'm not seeing any FAILs. Maybe it's not an
issue. ...or maybe an issue that will only turn up if someone tries
to use iostream in their C++ extension code.

Dave

[Sisyphus]

----- Original Message -----
From: "David Oswald" <daoswald-***@public.gmane.org>
To: "inline" <inline-***@public.gmane.org>
Sent: Sunday, August 26, 2012 6:08 AM
Subject: Libraries for MSVC++

Post by David Oswald
elsif ( $Config{osname} =~ m/^MSWin/ ) {
$cc_guess = 'cl -TP -EHsc';
$libs_guess = ' MSVCIRT.LIB ';
}
However, the docs I found here: http://support.microsoft.com/kb/154753
...suggest that library pertains to the old style iostream.h headers,
and that there are other options for the newer iostream headers.

Has it been established that the name of the lib that gets specified
actually matters ?
For my MSVC++ 7.0 compiler it doesn't seem to matter at all.

I can specify the non-existent "rubbish.lib" (at the Makefile.PL stage) when
building Inline::CPP with that compiler, and it doesn't make any difference
to the build (or the tests) afaict.

However, there are, of course, MS compilers other than MSVC++ 7.0.

Cheers,
Rob

[David Oswald]

Post by Sisyphus
Has it been established that the name of the lib that gets specified
actually matters ?
For my MSVC++ 7.0 compiler it doesn't seem to matter at all.
I can specify the non-existent "rubbish.lib" (at the Makefile.PL stage) when
building Inline::CPP with that compiler, and it doesn't make any difference
to the build (or the tests) afaict.
However, there are, of course, MS compilers other than MSVC++ 7.0.

I think that's an excellent question. And I think the answer is
probably 'no', in which case I ought to remove all library
specification for MSVC environments from Makefile.PL and add a
comment, so that I don't go chasing that lion's tail again in six
months when I've forgotten those platform specific details.

It might be worthwhile for me to produce another dev release with all
library specification removed from MSVC++ environments to see if it
breaks any tests. I'm guessing it won't. I should probably also add
a test that uses std::cout (if we're in a
__INLINE_CPP_STANDARD_HEADERS environment), just to be sure I'm not
breaking something.

Strawberry won't be affected, because it gets trapped by a different
logic branch in Makefile.PL.

Thanks for your input!

Dave