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

SOLVED!
Have a nice time perl monks! I have windows 7 HP 64bit and professional visual studio 2013. I want to call perl sub from c code. I looked at perlembed, found out that strawberry perl does not have perl520.lib, as it seems to be build with mingw. So I've tried to build perl myself. I've got sources and opened perl-5.20.2/win32/Makefile. I've uncommented:
I run Developer command prompt for VS2013. nmake seems to run fine. Then fun starts. nmake test hangs on perl_mb_opt 1/8. nmake install copies 809 files, but seems to fail to locate many modules, because it says(it is my translation, because my nmake is not english:( ): 'cannot locate or found any substitution for module *module name*'. Then when I try to compile the easiest example from perlembed 
#include <EXTERN.h>               /* from the Perl distribution     */
#include <perl.h>                 /* from the Perl distribution     */
static PerlInterpreter *my_perl;  /***    The Perl interpreter    ***/
int main ( int argc, char **argv, char **env )
{
    PERL_SYS_INIT3 ( &argc, &argv, &env );
    my_perl = perl_alloc ( );
    perl_construct ( my_perl );
    PL_exit_flags |= PERL_EXIT_DESTRUCT_END;
    perl_parse ( my_perl, NULL, argc, argv, ( char ** ) NULL );
    perl_run ( my_perl );
    perl_destruct ( my_perl );
    perl_free ( my_perl );
    PERL_SYS_TERM ( );
}

[download]
It fails to start with exception 0xc000007b. I tried everything I could think of: changes in makefile, launching console as administrator. Nothing seems to work at all. I'm confused. Please, help me somehow. Thank you.
EDIT
The most common problem which causes 0xc000007b exception is architicture discrepancy. But perl -v shows me MSWin32-x86 and my application also is built under win32 option.
/EDIT
SOLUTION

I'm complete moron.

I've launched "Developer Command Prompt for VS2013". Instead you should launch architecture dependant version of prompt like VS2013 x64 Native Tools Command Prompt It transforms error 0xc000007b to 'dll not found'


/SOLUTION

Replies are listed 'Best First'.
Re: Compiling perl on windows with visual studio
by syphilis (Archbishop) on Mar 24, 2015 at 23:52 UTC
    cannot locate or found any substitution for module *module name*'

    What are the actual names of some of these modules ?
    Are they *really* not installed ?
    Is your perl basically functional ? (ie can you run perl -V)

    Cheers,
    Rob
[reply]
[d/l]

      Yes, perl -v runs normally.

      'Cannot locate JSON:XS or cannot find suitable replacement. Cannot resolve link path'. And there are lots of them. I understand, that JSON is not the most necessary module)

[reply]
        Cannot locate JSON:XS ...

        These might be harmless POD link messages. JSON::XS doesn't get installed as part of perl (on my Windows perls, anyway) - its absence is to be expected.
        I think you can ignore those messages.

        Cheers,
        Rob
[reply]
Re: Compiling perl on windows with visual studio
by RonW (Parson) on Mar 24, 2015 at 21:59 UTC

    Under MS Windows, I would expect to see perl520.dll not perl520.lib

    Linking your C application with perl520.dll (or perl.dll) should work as long as your C source is compiled with the same (or equivalent) options as your installation of Perl.

[reply]
[d/l]
[select]
      .dll is compiled code. It needs some linker information, which is stored in .lib, so VS links code to .lib.
[reply]
Re: Compiling perl on windows with visual studio
by soonix (Chancellor) on Mar 25, 2015 at 06:24 UTC
    this guy is on a similiar quest. Perhaps his experiences are helpful (he's on 8.1 64bit, though).
[reply]
      Thank you!
[reply]
Re: Compiling perl on windows with visual studio
by BrowserUk (Patriarch) on Mar 25, 2015 at 06:40 UTC

    From a web search:

    0xc00007b error "the application was unable to start correctly"

    there may be multiple reasons as to why you might receive 0xc00007b error when trying to run an application on a windows machine. 0xc000007b error usually comes from mixing up 32bit environment with 64bit one. For example 32bit application loads a 64bit dll causing 0xc000007b error.

    Looks like you are mixing 32-bit built binaries with a 64-bit build, or vice versa.

    Post the console log from the build.

    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority". I'm with torvalds on this
    In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked
[reply]

      Yes, I've googled something like this. I uncommented WIN64 = undef so it means that I have 32bit perl, yes? Also perl-v shows MSWin32-x86.

      Build log is really long, which part should I post?

[reply]
        I uncommented WIN64 = undef so it means that I have 32bit perl, yes?

        You should uncomment that only if your Windows OS is 64-bit && your compiler is 32-bit.
        Maybe run "nmake distclean" and then try re-building with that line commented out .... see if that improves things ....

        Cheers,
        Rob
[reply]
Re: Compiling perl on windows with visual studio
by Anonymous Monk on Mar 24, 2015 at 23:32 UTC

    I'm confused. Please, help me somehow.

    Go back to using strawberryperl

    Go back to reading perlembed and use ExtUtils::Embed, it spits out the correct string with a full path to 

    $ perl -V:libperl
libperl='libperl516.a';
[reply]
      libperl.a does not help with visual studio
[reply]
[reply]

Back to Seekers of Perl Wisdom