dk has asked for the wisdom of the Perl Monks concerning the following question:

Brethren,

I need a help with a new facet of windows dll hell I recently discovered when I started to compile my own dlls from CPAN. The problem is that newer windows build mechanism ( MSVC Express 8.0 ) links newly created dll with MSVCR80.DLL, and not with MSVCRT.DLL as it was in the older days. And this creates a whole new set of problems discussed everywhere, namely when an executable (in my case, perl.exe) needs to have a special perl.exe.manifest to work properly with MSVCR80, -- which doesn't not work when binaries are distributed, for reasons unknown (more specifically, "perl -MWin32" isn't runnable when the manifest is present, and displays the cursed R6034 error when it is).

I looked inside perl.exe that comes from ActiveState and found that there's no string MSVCR80, but MSVCRT; however, I cannot find a way to build my DLLs so they would also refer to MSVCRT, they always refer to MSVCR80 when I build them. Probably I'm going in the wrong direction, but I thought if I could build my DLLs the way ActiveState's perl.exe is built, the problem will go away.

My question is twofold: does anyone know how to link a binary with MSVCRT using MSVC Express 8.0? I suspect if that's impossible, ActiveState folks might just use an older MSVC version, v6 for example. If that's so, then there's a problem, because MS warns about problems with applications that are linked with different versions of CRT library.

OTOH If I'm indeed going in the wrong direction, and there's a way to easily distribute custom-built DLLs of CPAN modules, how then one does so, and makes sure that they are runnable on all kinds of windows with all kinds of service packs with and without MSVCR80*DLL installed? I definitely cannot try myself all these combination, nor I want to, so I hope there's an easy way out. Thanks.

Replies are listed 'Best First'.
Re: win32: distributing dll hell
by bingos (Vicar) on Jun 19, 2007 at 09:49 UTC

    Yeah, ActiveState appear to still use Visual Studio 6 to compile ActivePerl:

    c:\>perl -V
Summary of my perl5 (revision 5 version 8 subversion 8) 
  Compiler:
    cc='cl', ccflags ='-nologo -GF -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 -D
+_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DNO_HASH_SEED -DUSE_SITECUSTO
+MIZE -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_
+MSVCRT_READFIX',
    optimize='-MD -Zi -DNDEBUG -O1',
    cppflags='-DWIN32'
    ccversion='12.00.8804', gccversion='', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
    d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='__int64
+', lseeksize=8
    alignbytes=8, prototype=define

    [download]

    12.00.8804 is VS6

    I use the VC++ Toolkit for compiling modules. On the whole this works. Of course the VC++ Toolkit is no longer available.

    A possible solution may be to compile Perl yourself using the newer Microsoft tools.

[reply]
[d/l]
Re: win32: distributing dll hell
by GrandFather (Saint) on Jun 19, 2007 at 10:04 UTC

    Bottom line: you can't. ActiveState's current distributions are using an older compiler than you are and they are (as you have found out) compiling against a different version of the run time library. You have to build against the same libraries that AS used which means really that you have to use the same version of the compiler that AS used. The alternative is to build everything, including Perl, but the down side of that is you have to build everything.

    You may be interested in Vanilla or Strawberry Perl as an alternative to the "build it from scratch" approach.

    DWIM is Perl's answer to Gödel
[reply]
      Compling perl with v8 is not a problem, the problem will be with the ability to redistribute the resulted binaries -- they will in turn require the all that .manifest monstrosity. I wonder what compiler backend Vanilla/Strawberry perl uses - is it msvc- or cygwin-based?
[reply]
        I wonder what compiler backend Vanilla/Strawberry perl uses - is it msvc- or cygwin-based?

        It uses the MinGW port of the gcc compiler - and hence uses the msvc runtime library. Vanilla/Strawberry binaries (dll's) therefore work fine on ActivePerl (and vice-versa, for that matter).

        However, as bart mentions elsewhere, you can use the very same MinGW port of gcc with ActivePerl anyway, if you want. (I don't think the performance issues you mentioned are significant, these days.)

        If you're committed to building with ActivePerl, then the best option is to use Visual Studio 6.0. If you can't acquire that compiler, then the next best thing is to use the MinGW port of gcc. http://www.perlmonks.org/index.pl?node_id=614808 may be of some help.

        I have also used Visual Studio 7.0 with ActivePerl without too much trouble - I don't think I'd even bother trying to use Visual Studio 8 with ActivePerl.

        Cheers,
        Rob
[reply]
Re: win32: distributing dll hell
by cdarke (Prior) on Jun 19, 2007 at 10:06 UTC
    Try statically linking your DLL with MSVCR80.DLL, rather than the .lib. That is inefficient, but a small price to pay.
[reply]
Re: win32: distributing dll hell
by bart (Canon) on Jun 19, 2007 at 11:04 UTC
    You can build modules for ActivePerl/Win32 with the MinGW compiler — which is free. There's no need to fall back on Strawberry Perl, or worse, build your own perl.
[reply]
      That's the long term goal, yes. I don't know how the things are now, but before I always experienced that perl compiled with gcc using cygwin/mingw runtime is significantly slower.
[reply]
        In what way? Is it startup time for perl, or the execution speed once it's running?

        AFAIK gcc has always had a reputation of making one of the better C compilers. So, I would not expect the code generated by gcc to run "slow".

        Cygwin requires use of a private DLL containing a linking layer between the internal Unix-like API and the native Win32 API, but MinGW allegedly builds real native Windows programs, that don't require an external DLL either, so I would expect MinGW to perform better, or at least not worse, than Cygwin.

        But those are my expectations, I do not have any benchmark data to back them up.

[reply]

Back to Seekers of Perl Wisdom