Perl usually hooks libc stuff like printf and malloc on win32 to make very old thread-unsafe XS code, thread-safe (the effort usually fails). Do a #undef printf to get back the real printf and not a hook into perl.

Wouldn't that affect the msvc build as well as the gcc build?

Anyhow, I tried it:

#include <EXTERN.h>
#include <perl.h>

EXTERN_C void xs_init (pTHX);

EXTERN_C void boot_DynaLoader (pTHX_ CV* cv);
EXTERN_C void boot_Win32CORE (pTHX_ CV* cv);

EXTERN_C void
xs_init(pTHX)
{
  char *file = __FILE__;

   dXSUB_SYS;

   /* DynaLoader is a special case */
   newXS("DynaLoader::boot_DynaLoader", boot_DynaLoader, file);
   newXS("Win32CORE::bootstrap", boot_Win32CORE, file);
 }

#undef printf

static PerlInterpreter *my_perl;  /***    The Perl interpreter    ***/

int main(int argc, char **argv, char **env) {
    printf( "So far, so good!\n" );
    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();
    return 0;
}
[download]

And still the gcc build produces no output:

C:\test>gcc_bld_hello.c.pl18

Building Hello
gcc -Wall -mwindows -o hello hello.c   -s -O2 -DWIN32 -DWIN64 -DCONSER
+VATIVE  -DPERL_TEXTMODE_SCRIPTS -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLIC
+IT_SYS -DUSE_PERLIO -fno-strict-aliasing -mms-bitfields  -I"C:\Perl5.
+18\perl\lib\CORE"    -s -L"C:\Perl5.18\perl\lib\CORE" -L"C:\Perl5
gw32\lib\libmpr.a C:\Perl5.18\c\x86_64-w64-mingw32\lib\libwinmm.a C:\P
+erl5.18\c\x86_64-w64-mingw32\lib\libversion.a C:\Perl5.18\c\x86_64-w6
+4-mingw32\lib\libodbc32.a C:\Perl5.18\c\x86_64-w64-mingw32\lib\libodb
+ccp32.a C:\Perl5.18\c\x86_64-w64-mingw32\lib\libcomctl32.a

In file included from C:\Perl5.18\perl\lib\CORE/sys/socket.h:180:0,
                 from C:\Perl5.18\perl\lib\CORE/win32.h:386,
                 from C:\Perl5.18\perl\lib\CORE/win32thread.h:4,
                 from C:\Perl5.18\perl\lib\CORE/perl.h:2869,
                 from hello.c:2:
C:\Perl5.18\perl\lib\CORE/win32.h:391:26: warning: "/*" within comment
+ [-Wcomment]
C:\Perl5.18\perl\lib\CORE/win32.h:392:33: warning: "/*" within comment
+ [-Wcomment]
In file included from C:\Perl5.18\perl\lib\CORE/win32thread.h:4:0,
                 from C:\Perl5.18\perl\lib\CORE/perl.h:2869,
                 from hello.c:2:
C:\Perl5.18\perl\lib\CORE/win32.h:391:26: warning: "/*" within comment
+ [-Wcomment]
C:\Perl5.18\perl\lib\CORE/win32.h:392:33: warning: "/*" within comment
+ [-Wcomment]

C:\test>.\hello.exe hello.pl18

C:\test>.\hello.exe hello.pl18

C:\test>
[download]

Whereas the cl build does what is expected:

C:\test>cl /W3 hello.c -DWIN32 -I"C:\Perl64\lib\CORE"  C:\Perl64\lib\C
+ORE\perl510.lib
Microsoft (R) C/C++ Optimizing Compiler Version 15.00.21022.08 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

hello.c
Microsoft (R) Incremental Linker Version 9.00.21022.08
Copyright (C) Microsoft Corporation.  All rights reserved.

/out:hello.exe
hello.obj
C:\Perl64\lib\CORE\perl510.lib

C:\test>.\hello.exe hello.pl
So far, so good!
Hello from MSWin32 5.010001
[download]

Downloaded MS SDK for Windows, run into issue: http://stackoverflow.com/questions/1901279/windows-7-sdk-installation-failure , solved as described, found that command-line compiler is not here anymore, downloaded Visual c++ Express Edition, run your example from above, found that there is a difference with perl 5.10 in comparison to 5.16, though found also that the file perl510.lib is not available with strawberry perl, despaired, then found an old 5.12-installation of ActivePerl with perl512.lib, run the example again, found that one should start vc command line with admin rights otherwise hello.proj cannot be read, run it again ... - and it worked!!!

Some questions if I dare :-):

How to set the output to a project directory (now the .exe is being saved in C:/windows/system32 which is not a good thing)?

How to bind the perl source file at the time of compiling (my naive attempt in the OP with setting argv does not work)?

In any case - Many Thanks!!! BrowserUK, it was a rare sense of achievement in the passing year for me!

After further experimenting: Update:

The perl source file can be included if provided with full path with double backslash.

Am I right that the lib folder from the project can be included for cl compiler on its command-line? The attempt with an empty lib folder produced no error.

I still cannot redirect the output of the cl compiler to the project folder :-(

How to set the output to a project directory (now the .exe is being saved in C:/windows/system32 which is not a good thing)?

That is very weird! The exe gets placed in the current working directory (unless you tell it to do otherwise), so why are you running the command in C:/windows/system32?

Personally, I always run the cl command in the project directory, and that's where the output goes; but if you really must place it somewhere else, you can use:

/Fe<file> name executable file
[download]

I assume you can specify a full path, though I've never tried it.

See cl -help for a good usage screen.

Am I right that the lib folder from the project can be included for cl compiler on its command-line?

Yes. Use /LIBPATH:path

See link /? for other linktime options that can be supplied to cl

---

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".

In the absence of evidence, opinion is indistinguishable from prejudice.

The perl source file can be included if provided with full path with double backslash.

Sorry it was a rapid shot, since I still need the perl source file at the runtime. The desired behavior were to pack the source file at the compile time. Is it possible?