Wondering if it is possible to build Synfig 1.0 on windows.
Is the developer documentation at wiki.synfig.org/wiki/Dev:Building_on_Windows up to date and can I expect that to work?
Does anyone have thoughts about porting the code to use Visual Studio 2013 rather than mingw?
Thanks for any input and guidance,
Chip
Wiki is out of date.
The only way to build for windows is to use the building script under autobuild folder from source code.
-G
which you need cygwin to run the building script.
It seems MinGW is not required for building Synfig on Windows.
What are the required Cygwin packages?
Thanks.
Quite a number of cygwin packages are required which are not stated in the wiki:
e.g git, wget, python, setuptools, mingw dll’s
$ bash C:/synfig-build/synfig/autobuild/synfigstudio-cygwin-mingw-build.sh
C:/synfig-build/synfig/autobuild/synfigstudio-cygwin-mingw-build.sh: line 95: git: command not found
chmod: cannot access ‘/usr/i686-w64-mingw32/sys-root/mingw/bin/*.dll’: No such file or directory
cat: /prep-done: No such file or directory
note: Hand installation over to elevated child process.
note: Hand installation over to elevated child process.
Building pyliblzma…
–2015-10-19 13:44:52-- pypi.python.org/packages/source … .3.tar.bz2
Resolving pypi.python.org (pypi.python.org)… 185.31.19.223
Connecting to pypi.python.org (pypi.python.org)|185.31.19.223|:443… connected.
HTTP request sent, awaiting response… 200 OK
Length: 43498 (42K) [application/octet-stream]
Saving to: ‘pyliblzma-0.5.3.tar.bz2’
pyliblzma-0.5.3.tar.bz2 100%[======================================================>] 42.48K 200KB/s in 0.2s
2015-10-19 13:44:54 (200 KB/s) - ‘pyliblzma-0.5.3.tar.bz2’ saved [43498/43498]
C:/synfig-build/synfig/autobuild/synfigstudio-cygwin-mingw-build.sh: line 256: python: command not found
$ bash C:/synfig-build/synfig/autobuild/synfigstudio-cygwin-mingw-build.sh
C:/synfig-build/synfig/autobuild/synfigstudio-cygwin-mingw-build.sh: line 95: git: command not found
chmod: cannot access ‘/usr/i686-w64-mingw32/sys-root/mingw/bin/*.dll’: No such file or directory
cat: /prep-done: No such file or directory
note: Hand installation over to elevated child process.
note: Hand installation over to elevated child process.
Building pyliblzma…
Traceback (most recent call last):
File “setup.py”, line 26, in
from setuptools import setup, Extension
ImportError: No module named setuptools
For the cygwin setup, site “http://www.mirrorservice.org/sites/sourceware.org/pub/cygwin” is very slow. Anyways, I had to use another site (“http://cygwin.mirror.constant.com/”) to complete the setup.
#-s http://www.mirrorservice.org/sites/sourceware.org/pub/cygwin/ \
$CYGWIN_SETUP \
-s http://cygwin.mirror.constant.com/ \
-P git \
I am still trying to identify all the required cygwin packages at the moment …
Austin
Steps I have taken so far:
#================= EDIT THOSE VARIABLES BEFORE FIRST RUN! ======================
export WORKSPACE="/cygdrive/c/cygwin/home"
export NSIS_BINARY="${WORKSPACE}/NSIS/makensis.exe"
if [ -z $ARCH ]; then
export ARCH="32"
fi
if [ -z $DEBUG ]; then
export DEBUG=1
fi
if [ -z $THREADS ]; then
export THREADS=4
fi
#=========================== EDIT UNTIL HERE ===================================
export DISTPREFIX=$WORKSPACE/dist
export SRCPREFIX=`dirname "$0"`
SRCPREFIX=$(cd "$SRCPREFIX/.."; pwd)
if [[ $ARCH == "32" ]]; then
export TOOLCHAIN_HOST="i686-w64-mingw32"
export TOOLCHAIN="mingw64-i686" # mingw64-i686 | mingw64-x86_64 | mingw
export EXT_ARCH=i386
export EXT_ARCH2=i686
export CYGWIN_SETUP="${WORKSPACE}/cygwin-dist/setup-x86.exe"
export SZIP_BINARY="7z"
elif [[ $ARCH == "64" ]]; then
export TOOLCHAIN_HOST="x86_64-w64-mingw32"
export TOOLCHAIN="mingw64-x86_64"
export EXT_ARCH=x86_64
export EXT_ARCH2=x86_64
export CYGWIN_SETUP="${WORKSPACE}/cygwin64-dist/setup-x86_64.exe"
export SZIP_BINARY="${WORKSPACE}/7zip/7z.exe"
fiStill running at the moment …
eausaig@NG00042732 /cygdrive/c/cygwin/home/synfig
$ bash autobuild/synfigstudio-cygwin-mingw-build.sh mkprep
chmod: cannot access ‘/usr/i686-w64-mingw32/sys-root/mingw/bin/*.dll’: No such file or directory
Executing custom user command…
cat: /prep-done: No such file or directory
Starting cygwin install, version 2.873
User has backup/restore rights
Current Directory: C:\cygwin\home\cygwin-dist
Could not open service McShield for query, start and stop. McAfee may not be installed, or we don’t have access.
root: C:\cygwin system
Selected local directory: C:\cygwin\home\cygwin-dist
net: IE5
site: cygwin.mirror.constant.com/
Adding required dependency autoconf2.1: Selecting version 2.13-12 for installation.
Adding required dependency autoconf2.5: Selecting version 2.69-3 for installation.
…
Adding required dependency libjpeg8: Selecting version 1.4.2-1 for installation.
Adding required dependency liblcms2_2: Selecting version 2.6-1 for installation.
Adding required dependency perl-Devel-Autoflush: Selecting version 0.06-2 for installation.
Adding required dependency perl-Devel-Symdump: Selecting version 2.15-1 for installation.
Downloaded C:\cygwin\home\cygwin-dist/http%3a%2f%2fcygwin.mirror.constant.com%2f/x86/release/ImageMagick/ImageMagick-6.9.1.3-3.tar.xz
Downloaded C:\cygwin\home\cygwin-dist/http%3a%2f%2fcygwin.mirror.constant.com%2f/x86/release/autoconf/autoconf-13-1.tar.bz2
Downloaded C:\cygwin\home\cygwin-dist/http%3a%2f%2fcygwin.mirror.constant.com%2f/x86/release/autoconf2.1/autoconf2.1-2.13-12.tar.bz2
Downloaded C:\cygwin\home\cygwin-dist/http%3a%2f%2fcygwin.mirror.constant.com%2f/x86/release/autoconf2.5/autoconf2.5-2.69-3.tar.xz
Downloaded C:\cygwin\home\cygwin-dist/http%3a%2f%2fcygwin.mirror.constant.com%2f/x86/release/automake/automake-9-1.tar.bz2
Downloaded C:\cygwin\home\cygwin-dist/http%3a%2f%2fcygwin.mirror.constant.com%2f/x86/release/automake1.10/automake1.10-1.10.3-2.tar.bz2
Downloaded C:\cygwin\home\cygwin-dist/http%3a%2f%2fcygwin.mirror.constant.com%2f/x86/release/automake1.11/automake1.11-1.11.6-2.tar.bz2
…
Is MinGW required when installing Cygwin?
What is the essence of the following lines in “synfigstudio-cygwin-mingw-build.sh”?
export MINGWPREFIX="/usr/${TOOLCHAIN_HOST}/sys-root/mingw"
...
chmod a+x ${MINGWPREFIX}/bin/*.dll || trueeausaig@NG00042732 /cygdrive/c/cygwin/home/synfig
$ bash autobuild/synfigstudio-cygwin-mingw-build.sh mkprep
chmod: cannot access ‘/usr/i686-w64-mingw32/sys-root/mingw/bin/*.dll’: No such file or directory
The versions of libraries required for building Synfig are quite strict.
From my experience, it is better to use MinGW with Cygwin and the script is a bit limited but fonctionnal.
It would be better to port it to CMake to generate all the projects versions, nut it works 
See wiki.synfig.org/Dev:IDE_Windows for more details 
Is there any possibility that we could get more information/clarification/assistance here?
While this looks like an awesome program once its up and running, we on windows are largely shut out of the fun. 
I can confirm that the methods suggested by the documentation, both by the wiki and by the header in the autobuild file, do not result in a successful compile, even for an experienced code monkey. I’ve been coding since color monitors were a cool novelty and installed motherboard drivers via command line. I know what I am doing around code. It also took me two days to coax the program into what I think might be a successful 64bit windows compilation, using a mix of suggestions from this thread and a crash course in linux-to-human-to-windows translation.
What’s really needed to help fix all this is…
I’m sorry if this sounds like ranting or trolling here. That is not my intention. I deeply respect the huge amount of work ya’ll have put into and continue to put into this project for little to no pay. I am legitimately just trying to clearly state the problem, which based on a search of the threads has been ignored for a long time: The windows autobuilder and its documentation are badly broken. And some of us would love to see that fixed, or at least acknowledged. Please? 
As an addendum to my previous comment, I did not in fact succeed in compiling a 64bit version, but rather inadvertently rolled back the autobuild file so that it compiled a 32bit version (Which, incidentally, still displays the error where my wacom stylus is locked to window mode and the cursor is offset up and left by about a hundred pixels each. Once I figure out how to compile in 64bit I’m planning to try gutting all options but straight 1-1 screen mode from the program and see if that fixes the problem. 
)
keeps getting stuck at the end of the mkimagemagic stage with a full 64bit compile, and at:
“checking for glibmm-2.4 >= 2.24.2… configure: error: ** You need to install glibmm-2.4 version 2.24.2 or higher.”
in the mksynfig stage with a piecemeal compile skipping mkimagemagic. 32bit succeeds other than tablet support being broken, though.
Note, for troubleshooting purposes, that I do have glibmm-2.4 installed. 
Wiki build instructions for windows are outdated (and probably the rest of platforms too). Since those instructions were made many new libraries have been added to build Synfig Studio. There is not other way to build packages/binaries than run the scripts under autobuild folder from the source code.
The script is just a sequence or commands and those are just what you should do manually to make the package or build de binaries. Why do it manually when the script allows to make it automatically?
Again, anything outside the script is just a hell.
-G
Therein lies the problem.
Trying to create a 64bit build using the autobuilder is also hell.
Even after figuring out that you have to alter the variable in the autobuilder script to compile as 64 bit (which is never explained anywhere, and if there is another way we should be doing this, this is also not explained), the compile sequence the autobuilder attempts will fail at the points I mentioned.
Unless there is some vital step which the autobuilder’s instructions fail to mention causing said failure- and several days of research and troubleshooting seem to suggest there is not- the autobuild script is broken for windows 64 bit.
It does not function properly.
Es ist kaputt. Está roto. оно сломано. Il est cassé.
Is there any chance of it getting fixed?
Hi,
I tried to compile Synfig 32bit on Win 8.1 x64 and encountered the same issues about LZMA.
I followed the content of the header of the script and reinstalled cygwin from scratch.
I had to add manually libpcre packages in cygwin in order to be able to compile.
I will do some other tests and report.
(January 12 2016, version 1.1.4 master)
Edit: Confirmed successful build after installing pcre libs before to run “bash autobuild/synfigstudio-cygwin-mingw-build.sh”
Hello, scorpion451.
My name is Konstantin Dmitriev, I am maintainer of Synfig and I am the one who wrote this awkward/hell script for windows. Unfortunately, I haven’t had time to document all its features, because I am maintaining build scripts for Windows, Linux and OSX at the same time. Also, I have more terrific scripts, that allow to corsscompile WIndows build of Synfig on Linux. This is exactly the one that we use for generating our Windows binaries. I appreciate your help if you help to document your discoveries about script functionality in the script body.
Back to topic.
Please take a look at synfig.org/cms/en/download/ (“development builds” section at the bottom).
This one link is also your friend: download.tuxfamily.org/morevna/p … g/windows/
Please see beginning of my post.
As you understand, the compile script relies on Cygwin. From time to time Cygwin guys change something and this is how it gets broken. For example, they can split some package into two and thus we get uncomplete list of dependencies. The problem here is not with Cygwin guys. The problem is that we build Synfig on Windows in rare cases. As I mentioned before, I build Windows version of Synfig on Linux (that’s faster and helps me to be sure that the built binary isn’t affected by some trojan or anything else).
And here comes one more thing.
YOU RIGHT: Building 64bit version of Synfig on Windows is really hell. It is possible to get 64bit build, but only if DEBUG mode is off. If denug mode is on, then it will fail, because some of compiled binary (synfigstudio.exe, but I don’t remember exactly) grows bigger than 2GB (because of debug symbols included) and that makes compilation process fail. I’ve hit that problem, when I was trying to get 64bit build on Windows last time and I haven’t managed to resolve it. And yes, I do have filesystem that allows files more than 2GB. 
So, you can’t compile debug version of synfig on WIndows. Without debug build it’s very hard to do any development.
Quick addition: I pretty sure, that 64bit build won’t solve your tablet problems. From my experience 32bit and 64bit Windows builds are identical in terms of bugs. In all cases that I recall, fixing a bug for Win32 build automatically fixes it for Win64 build. Again, you can test your issue with the latest 64 builds here - download.tuxfamily.org/morevna/p … g/windows/
I will be happy to answer any of your other questions.
P.S. BobSynfig: thanks for hint, I have added missing dependency.
That’s why you should make the conversion to cmake build set up years ago. What’s the hold up? You are even using crowed funding at this point of time. There shouldn’t be any excuses at this point of time. I suggest the switch around 4-8 years ago. When I join this website I was a high schooler freshman who has too much time on their hands. Now? I’m a a senior CS college student who currently focusing his school work and thinking about how he is going to pay the federal loan back. That outta give you the time perspective on how much time has passed.
I swear to god, that some open source advocates treat windows development as a red step child even though that where the MAJORITY OF USERS/DEVELOPERS COME FROM. Do you have any idea how annoying that feels?!That feeling of neglected and frustrations of not being treating seriously?! Let me tell you, NOT PLEASANT. Then these clowns keep scratching their head wondering why it their software is not popular. I should know, because I’m participate in spring rts developments on the windows side of things, creating and helping maintaining the build slave for MS visual studio.
You can’t just rely on open source “magic” and expect other to fix it for you, when your community is that small to be begin with! You shouldn’t expect nor be entitled others to fix your stuff either, when they point out problems from the developer/users side of things. You have to fix the issues that is arise by them by yourself if you wanted developers/users that badly. Once you do that, then people will be more incline to help, as you have shown you take issues seriously and not just side step it with excuses for example “works for me” or “you don’t need that” (Believe me, that one of the reasons why I despise Linux advocates, their general apologias is hair ripping). That or rely on their self interest in this (which I hardly seen any one who have that interest).
So in all, here are some of my advise.
Do not take a poor man’s approach on this by compiling the Windows binary on Linux systems. Seriously, stop it. Too many Linux developers think that their the typical build setup will easily transfer to Windows with ease. This isn’t the case when you’re using the build system such as autotools that isn’t design with cross compiling in mind. Buy a windows license. If you can’t afford it then use the crowd funding to fund it then. That way you capture bugs, before you release the build to the public.
It is atrocious to learn and to use, especially if your developing for cross platform. This summrizes the problems with it. So I am going to be dug from pixar’s up and say please please please please please PLEASESSSSSSSS STOP USING AUTOTOOLS BUILD SYSTEM!!! The KDE devs rightfully abandoned it and switch to the cmake build system. You guys should too. Stop the development of synfig, and start working on migrating to cmake. Please I BEG YOU, you will find cross development with Windows MUCH EASIER I CAN ASSURE YOU!!
That’s part of the reason of how blender got so popular over the years. You need to show them what it can do. You need to impress them. Don’t simply tell them what it can do, the internet doesn’t care about that. You need to show them why they should use your software instead of other software that is currently being distributed over the internet. Unique selling point is the key factor here. Open source is not a key factor for majority of users.
Yes, I am not using Windows in my daily routines of animation. One man say: “stop using Linux and use Windows RIGHT NOW”. Then other man comes and say: “use OSX, because the OSX users pay more”! And third man comes and say: “Linux people need animation software, why you use Windows/OSX?” And they all right. But hey, there is a fourth man, who say: “Why do you spend all days debugging Synfig? You need to make some impressive animation with it! This is your dream to make animation!”
What can I say? All those 4 people live inside of me at the same time. They all right.
I agree that cmake is better than Autotools. But you don’t really see the problem. Migrating to cmake won’t solve all problems. In order to ship Synfig, we still have to compile all its dependencies (gtk, glib, imagemagick and 10+ more. And the dependent packages aren’t use cmake, believe me.
That’s exactly, what I am doing last years - morevnaproject.org/anime/demo/
You can follow our progress here - morevnaproject.org/blog/
This isn’t about motivation, this is about software development. You just simply needed to make sure that it complies on the windows system with ease and to test it to find any particular bugs that are exclusive to windows. You can do the majority of coding of Linux for all I care, you just need to make sure that a build system for windows platform isn’t a nightmare. I have given up, all attempts on this years ago, because of this.
That’s your problem, you shouldn’t need to compile the dependencies in order to redistribute the software in the first place!! If you do that, then it implies that the dependence itself doesn’t have official windows support and needs to compile for the windows systems. If that were the case, then simply don’t use it at all. Don’t make your life harder than it actually is, by providing support for them. Use prebuild libraries for window/linux platform that the dependencies provide, as much as you can.
I know that, you haven’t made much noticeable process over the years though. It still hasn’t been officially released yet. You started this project at what? 2010? It’s been years!! I have given that up long time ago. I was thinking along of lines of a 5 minute video showcasing all the features that synfig has to offer. Not that overly ambitious project you currently have.
Hi superanimator!
Why don’t stop complaining and simply start by yourself by migrating Synfig build system from autotools to cmake?
That would sum to the project. Your current attitude just adds negativity to it.
Please focus your frustration on contribute.
Cheers!
-G
