MoarVM build fails with Strawberry Perl 5.22 C-tools and cygwin but can work with a little help.

[ronaldxs]

I am running Windows 7 with Strawberry Perl (64-bit) 5.22.0.1 and a Cygwin64 that is believed recent and up to date with c:\cygwin64\bin being at the very end of the PATH and Strawberry Perl components including C tools earlier in the path. I was trying to build Perl 6 with rakudobrew and noticed that MoarVM would not build because of a 3rdparty library called dyncall.

If I just check out MoarVM, "perl Configure.pl" runs OK but gmake (from Strawberry Perl) fails with an error that looks like:

dyncall_callf.c: In function 'void dcVCallF(DCCallVM_, DCValue_, DCpointer, const DCsigchar_, a_list)':
dyncall_callf.c:90:75: error: invalid conversion from 'DCpointer {aka void_}' to 'DCstring {aka const char*}' [-fpermissive]
case DC_SIGCHAR_STRING: result->Z = dcCallPointer (vm,funcptr); break;

More detailed error output is included below. I have researched the cause of this failure and feel I understand the cause fairly well, have a bypass for the problem and can propose some possible fixes.

dyncall is built in my Makefile with a line that looks like:

$(CMD)cd 3rdparty\dyncall && .\configure.bat /target-x64 /tool-gcc && $(MAKE) -f Makefile.embedded mingw32 $(NOOUT)

Going into 3rdparty\dyncall and trying to build it manually I notice that "gmake -f Makefile.embedded mingw32" is compiling .c source files to object files with g++ instead of gcc. If I use cygwin gnu make which happens on my system to be called just "make", dyncall builds successfully with a similar command. After much experimenting and digging I come across a gnu make bug, documented by gnu here: https://savannah.gnu.org/bugs/index.php?46304, that is causing Strawberry Perl gmake.exe to compile with g++ when it probably shouldn't and should be compiling with gcc which works for dyncall.

Essentially the bug, which when understood suggests a bypass and possible fixes, makes gmake under windows for some builds default to the following for .c compiles:

%.o: %.c
$(COMPILE.C) $(OUTPUT_OPTION) $<

Notice that the COMPILE.C is all caps and is confusing the ".c" extension for 'C' with the ".C" extension which is treated as 'C++'.

If you rebuild MoarVM from scratch, run "perl Makefile.PL" and then edit the MoarVM Makefile to change

$(CMD)cd 3rdparty\dyncall &amp;&amp; .\configure.bat /target-x64 /tool-gcc &amp;&amp; $(MAKE) -f Makefile.embedded mingw32 $(NOOUT)

to

$(CMD)cd 3rdparty\dyncall &amp;&amp; .\configure.bat /target-x64 /tool-gcc &amp;&amp; $(MAKE) COMPILE.C=$$(COMPILE.c) -f Makefile.embedded mingw32 $(NOOUT)

now I can run gmake and the build seems to run to completion.

So manually editing the file is one of a few bypasses. Having Configure.pl run "gmake -p -q" and dump the default rules could detect the problem and we could then insert the COMPILE.C=$$(COMPILE.c) or we could just assume that dyncall doesn't use 'C++' and always use it with gmake.

I look forward to other suggested fixes, if any, with interest.

Ron Schmidt

Detailed compile error from default build:
Host OS: windows
Target OS: windows
Target Architecture: x64
Compiler: gcc
Assembler: as
Build configuration: release
Install prefix: C:\Users\Ron\proj\MoarVM\3rdparty\dyncall\install_windows_x
64_gcc_release
Build prefix: C:\Users\Ron\proj\MoarVM\3rdparty\dyncall\build_out\windows
x64_gcc_release
ar: creating libdynload_s.a
dyncall_callf.c: In function 'void dcVCallF(DCCallVM, DCValue_, DCpointer, cons
t DCsigchar_, va_list)':
dyncall_callf.c:90:75: error: invalid conversion from 'DCpointer {aka void_}' to
'DCstring {aka const char_}' [-fpermissive]
case DC_SIGCHAR_STRING: result->Z = dcCallPointer (vm,funcptr); br
eak;
^
gmake[3]: *_* [dyncall_callf.o] Error 1
gmake[2]: *** [all] Error 2
gmake[1]: *** [mingw32] Error 2
makefile:595: recipe for target '3rdparty\dyncall\dyncall\libdyncall_s.a' failed

[ronaldxs]

It turns out this build problem occurs with Strawberry Perl 5.22 but does not happen with Strawberry Perl 5.20 which seems to have a somewhat different gmake.

[bdw]

This should be fixed by the workaround in commit 1278211