0.63.05 failing to build under windows


Hi Genete,
Synfig core is building OK, but it doesn’t seem to be able to render the splash screen, crashing instead. If I run it from the command line, it looks like I’m running into stack issues.

0\home\cnorman\synfig\temp\synfig-devel\bin\synfig.exe --version
synfig 0.63.05

0\home\cnorman\synfig\temp\synfig-devel\bin\synfig.exe -q …\images\splash_sc
reen-0.63.05.sif -o splash_screen.png --time 0
synfig(2808) [10:45:10 PM] info: Loading modules from C:/msys/1.0/home/cnorman/s
0 [main] us 0 init_cheap: VirtualAlloc pointer is null, Win32 error 487
AllocationBase 0x0, BaseAddress 0x68540000, RegionSize 0x80000, State 0x10000
c:\msys\1.0\home\cnorman\synfig\temp\synfig-devel\bin\synfig.exe: *** Couldn’t r
eserve space for cygwin’s heap, Win32 error 6


Any ideas?



It is possible that you didn’t fully rebuild synfig-core and there are mixed libraries?
Did you rebuild ETL too? It has upgraded.
Other sifz files show the same? Try pirates.sifz our beast crasher file.
Other than that I just can suggest clean all the .dll and other configuration files created and start it over.
Maybe change the build installation path to other place on the build script.

Alternatively, can you rewind to 0.63.04 and try to rebuild. Is it possible to try to rebuild on intermediate commits to see which is the one which is causing the bad synfig-core?

Good Luck!


This was a clean build. I’m regressing back to earlier versions to see if I can find out where it broke.
I have another idea I can try when I find out where that is…

Maybe it’s time to bite the bullet and figure out what it will take to move to MS VC.



0.63.04 still builds. Moving forwards to tag ‘genete key events’

I don’t know if it’s relevant, but on 0.63.05, every time vector.h is included, I see

[code]> …/…/…/src/synfig/vector.h:56:1: warning: “isnan” redefined

…/…/…/src/synfig/vector.h:42:1: warning: this is the location of the previous definition[/code]

Looks like the fix for Mac is being applied under Win32 too.


tag ‘genete key events’ works. Now checking tag ‘eldruin clang fixes’


tag ‘eldruin clang fixes’ works too. Bedtime.


This is the branch that touches the vector.h file for clang fixes.
In any case the re definition is clear.

38 #ifdef WIN32 39 #include <float.h> 40 #ifndef isnan 41 extern "C" { int _isnan(double x); } 42 #define isnan _isnan 43 #endif 44 #endif 45 46 // For some reason isnan() isn't working on macosx any more. 47 // This is a quick fix. 48 #if defined(__APPLE__) && !defined(SYNFIG_ISNAN_FIX) 49 #ifdef isnan 50 #undef isnan 51 #endif 52 inline bool isnan(double x) { return x != x; } 53 inline bool isnan(float x) { return x != x; } 54 #define SYNFIG_ISNAN_FIX 1 55 #else 56 #define isnan std::isnan 57 #endif

This code is included in color.h too. When one of them is included first then the second redefines isnan for Windows because SYNFIG_ISNAN_FIX is already defined and so it enters the else condition at line 55 which redefine isnan in any platform.

This must be changed by a nested definition like this (or similar):

#ifdef WIN32 #include <float.h> #ifndef isnan extern "C" { int _isnan(double x); } #define isnan _isnan #endif #else // For some reason isnan() isn't working on macosx any more. // This is a quick fix. #if defined(__APPLE__) && !defined(SYNFIG_ISNAN_FIX) #ifdef isnan #undef isnan #endif inline bool isnan(double x) { return x != x; } inline bool isnan(float x) { return x != x; } #define SYNFIG_ISNAN_FIX 1 #else #define isnan std::isnan #endif #endif


In my opinion moving to MS VC looks like a really bad idea, as it might be even less compatible ==> more issues.
If I’m not mistaken, mingw gcc is more compatible with linux gcc than MS VC…


I’m sorry, I introduced the bug when applying htodd patches. I didn’t noticed, and compiling in Linux didn’t bring up the issue.
My apologies.

I started trying the CMake building sytem transition yesterday and so far I’m able to compile libsynfig, synfig-tool and some modules but I’ll need some time to support everything our current building system does.
I hope, after this the multi-platform compilation will go somewhat better so we can check every platform beforehand.
Wish me luck!


‘eldruin master’ works too.


Well, the good news is that I have a working build of 0.63.05. The bad news is that I had to build it by hand.

The build was failing because when trying to build 0.63.05 splash screen under msys, there’s a stack overflow. I got round it by reverting back to the 0.63.04 splash, manually tweaking the version number, and substituting it. Synfig can render that when running under msys just fine. There’s something about the new feature of outline grow that causes synfig to trigger a stack overflow in msys.

[code]Compare: (<)C:\msys\1.0\home\cnorman\synfig\build\synfig-studio\images\splash_screen-0.63.05bad.sif (173079 bytes)
with: (>)C:\msys\1.0\home\cnorman\synfig\build\synfig-studio\images\splash_screen-0.63.05good.sif (172233 bytes)


              <real value="1.0000000000"/>


Strangely, the resulting Synfigstudio is happy to render 0.63.05 splash screen when running native under Windows.



We intentionally included the outline grow feature in the new splash screen apart of change the bottom text.
If you failed to render that splash, it means that the synfig libraries were not build properly before build synfigsytudio.
Maybe it was still using the path of the already installed synfig CLI (previous version) and not the newly build libraries. It is worth to review the paths used during build time of synfigstudio to verify that it is using the current latest version of synfig libraries.

In linux/unix it is made this way:

export PKG_CONFIG_PATH="$prefix/lib/pkgconfig"
export PATH=$(pwd)/synfig-core/src/tool/.libs:$PATH
export CXX="/usr/bin/ccache /usr/bin/g++"


The interesting part is this one:
export PATH=$(pwd)/synfig-core/src/tool/.libs:$PATH

Notice that the .libs folder is added to the PATH. It is where the tool libraries are stored temporarily after make. You should do the similar in your build scripts.

I hope it helps