Linux binaries for 0.64.0 (candidate #3)


Please try to define ACLOCAL_FLAGS variable instead of moving intltool.m4 file


Setting the ACLOCAL_FLAGS doesn’t seem to make a difference one way or the other. :frowning:
I get the syntax error in configure, unless I copy the intltool.m4 in to the aclocal dir when I get the possibly undefined macro and autoreconf failing with exit status 1.


What version of components are people using? I know some of the pieces I have are ancient (but they were working until now). Specifically, do we have a minimum version of automake? :question:


Hi, Pixelgeek!
Attaching full list of library versions used for OSX build.
I hope that help.
build-info.txt (5.16 KB)


And in tonight’s news, after some hunting, hammering, assembly and coercion, I have somewhat modern versions of m4, autoconf and automake (only a couple of years old instead of a decade). Next failure is perl 5.8.1 which is required for intltool. This seems a good place to stop for the night. (I like to leave off when I have a plan for what to do next :slight_smile: )


Good sign …
go Pixelgeek go!!


OK - going to need some more inspiration here…

Perl versions - using MSYS version 5.8.8 gives me this error.

checking for XML::Parser... configure: error: XML::Parser perl module is required for intltool
From googling the web, this is a know issue and there are many recommendations to use the Activestate Perl.

I grabbed Activestate Perl 5.16.3. With this one I get the error

Synfig-Core... Applying patches... Synfig-Core... Configuring You should add the contents of `/usr/share/aclocal/libtool.m4' to `aclocal.m4'. You should add the contents of `/usr/share/aclocal/ltdl.m4' to `aclocal.m4'. Putting files in AC_CONFIG_AUX_DIR, `config'. ./ /bin/autoreconf: /bin/perl: bad interpreter: No such file or directory
more googling[code]
2008-06-06 Tor Lillqvist

* (GenerateHeaders): If running under
ActiveState Perl then prefix the intltool-extract command with the
Perl interpreter pathname, as the system() function has no clue
about Unixish executable scripts indicated by just a hashbang

(The MSYS Perl, as it runs on a Unix emulator, would be able to
run executable scripts based on their hashbang lines just fine,
but then MSYS Perl doesn't come with XML::Parser. Installing
XML::Parser for MSYS Perl is somewhat hard. So usually when using
mingw+MSYS to build GNOMEish software one wants to use
ActicveState's Perl to run the intltool scripts, even if the
built-in MSYS Perl is good for other Perl uses.)

Fix up Perl path in autoreconf

Configuring Can't locate Autom4te/ in @INC (@INC contains: /usr/share/autoconf c:/Perl/site/lib c:/Perl/lib .) at C:/msys/1.0/bin/autoreconf line 40. BEGIN failed--compilation aborted at C:/msys/1.0/bin/autoreconf line 40.
I don’t know why it’s complaining. I can see the file just fine… What a mess… Time for bed…


OK. Stepped back and reinstalled msys perl

Finally found the magic incantation to use the activestate Perl just for intltool…

export INTLTOOL_PERL="/c/Perl/bin/perl"

Now I’m running into the following error - C:/msys/1.0/home/cnorman/synfig/temp/synfig-devel/include/synfig-0.0/synfig/color.h:732: warning: passing `float' for converting 1 of `synfig::CairoColor& synfig::CairoColor::set_a(unsigned char)' ../../../src/synfigapp/main.cpp:34:17: pwd.h: No such file or directory ../../../src/synfigapp/main.cpp: In static member function `static void synfigapp::Main::set_interpolation(synfig::Interpolation)': ../../../src/synfigapp/main.cpp:321: warning: statement has no effect make[3]: *** [libsynfigapp_la-main.lo] Error 1 make[3]: Leaving directory `/home/cnorman/synfig/build/synfig-studio/win32build/src/synfigapp' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/cnorman/synfig/build/synfig-studio/win32build/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/cnorman/synfig/build/synfig-studio/win32build' make: *** [all] Error 2 Sun May 26 20:27:45 PDT 2013 Done.
Any suggestions?
[edit - meh, looks like pwd.h is a boost header file. I thought I’d got past futzing with that]
I’ll dig some more tomorrow, but for now it seems like a good place to stop.


one more step ! outch … one more stop …


  • POSIX Standard: 9.2.2 User Database Access <pwd.h>
    */ … 18556.html

Has windows os is no really posix … could be hard …
i think the question is why pwd.h is included there ?
is pwd.h really needed in synfig ?

./synfig-studio/src/synfigapp/main.cpp: struct passwd* pwd = getpwuid(getuid());

ok i got something … in main.cpp just banish pwd.h …

35> #ifndef WIN32
36> #include <pwd.h>
37> #endif

and that should work further :wink:


Yes djay, I like your thinking. Looking at the code, the use of pwd is actually conditionally compiled depending on the target. It seems like this was overlooked when the header file was added in. Recompiling with your suggestion.


Another step closer… now, ../../../src/synfigapp/pluginmanager.cpp: In member function `bool synfigapp::PluginLauncher::execute(std::string)': ../../../src/synfigapp/pluginmanager.cpp:149: error: `argv' was not declared in this scope ../../../src/synfigapp/pluginmanager.cpp:149: warning: unused variable 'argv' ../../../src/synfigapp/pluginmanager.cpp: In member function `void synfigapp::PluginManager::load_dir(const std::string&)': ../../../src/synfigapp/pluginmanager.cpp:234: warning: unused variable 'rc' make[3]: *** [libsynfigapp_la-pluginmanager.lo] Error 1 make[3]: Leaving directory `/home/cnorman/synfig/build/synfig-studio/win32build/src/synfigapp' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/cnorman/synfig/build/synfig-studio/win32build/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/cnorman/synfig/build/synfig-studio/win32build' make: *** [all] Error 2 Mon May 27 11:04:18 PDT 2013 Done.

Time to fix up the python dependency


Quick and dirty hack to get it to compile (I don’t even know if it will work)[code]#ifdef WIN32
String dir;
python_path = etl::dirname(etl::dirname(dir)+ETL_DIRECTORY_SEPARATOR+“python”+ETL_DIRECTORY_SEPARATOR+*iter+".exe");

Now failing as it tries to create the sif files for the installer_logo.

The procedure entry point FT_GlyphSlot_Embolden could not be located in the dynamic link library freetype6.dll which probably means that it’s picking up the wrong dll from somewhere. Or I need to update the dll.


So close…

C:\msys\1.0\home\cnorman\synfig\temp\synfig-devel\bin>synfig.exe --help synfig(3432) [3:31:32 PM] info: Loading modules from ../etc/synfig_modules.cfg 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

I seem to remember that this was the issue that we had that meant that we had to keep using Win XP rather than moving to Win7. :frowning:


In recent compil’ battle (wheezy one), i was also stuck with something similar… but boost already installed.
I went threw revising other dependencies, installing missing one and that resolve the case !
Feel like there are some “gremlins in the fridge” throwing libboost error but not the right one.

Hey dear pixelgeek, do you have fresh news of your own compil’ battle ?

see ya!


What’s the status of the 0.64.0 windows build attemps? Any progress? Anyone seen the light? :smiley:


Unfortunately I think I’ve hit the wall as far as we can go with the MSYS build environment. Everything compiles fine, but the resulting synfig.exe is unable to run. Zelgadis is having some success with the fedora cross compile environment, so I’m hoping that he’ll be able to pick up the Windows build torch (and I can get back to using Synfig instead of fighting with it).



Best of Luck



Yes, I was a bit busy last weeks with other things, but I plan to back for resolving the Windows build problem soon.

Pixelgeek: can you please share your .msi file which you use for creating synfig bundle? I have mine, but looks like yours have some additional features which I can pick into my version.


Maybe this hasn’t noticed by anyone yet.
In a Windows XP 32 bits I had installed Synfig Studio 0.63.05. Then installed 0.64.0 cross compiling. Then re-installed Synfig Studio 0.63.05. The last installer requested to uninstall the previous version first. Then I installed 0.63.05. The 0.63.05 version become fully unstable and crashes making it impossible to do anything.

I think that the uninstaller of 0.63.05 was leaving something back form 0.64.0 that was causing the crashes. Better to call the 0.64.0 uninstaller first and then the 0.63.05 installer just in case someone want to get back to stable version.



Genete, thanks for the note. The best way to uninstall 0.64.0 is to remove the Synfig directory completely. :slight_smile:

Here’s the thread for those who want to follow the progress of my work on Windows binaries -