Thanks d.j.a.y. , but with all this beautiful weather you sent, I won’t want to stay inside and hammer on the build…
it’s raining this afternoon, cause of the snow melt ? anyway,
sometime annoying bug are easier to catch nowhere from the sparkle screen !
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking dynamic linker characteristics... Win32 ld.exe
Patching libtool... patched
../configure: line 19481: syntax error near unexpected token `0.35.0'
../configure: line 19481: `IT_PROG_INTLTOOL(0.35.0)'
Making Synfig-Studio...
Making
make: *** No rule to make target `package'. Stop.
Mon May 6 20:12:16 PDT 2013
Done.
Now finding issues in studio. What version of intltool do I need?
Chris
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking dynamic linker characteristics... Win32 ld.exe
Patching libtool... patched
../configure: line 19481: syntax error near unexpected token `0.35.0'
../configure: line 19481: `IT_PROG_INTLTOOL(0.35.0)'
Making Synfig-Studio...
Making
make: *** No rule to make target `package'. Stop.
Mon May 6 20:12:16 PDT 2013
Done.
Now finding issues in studio. What version of intltool do I need?
Chris
Hi, pixelgeek!
Please don’t forget to run bootstrap.sh file in the synfig-studio dir before running ./configure
Any version of intltool >= 0.35 should fit.
I have posted a quick update for the build instructions: wiki.synfig.org/wiki/index.php?t … ldid=17335
Also, please include python3 into installation. In win32 case synfig will be looking for python binary in INSTALL_PREFIX/python/python.exe or INSTALL_PREFIX/python/python3.exe
(see this commit for details: github.com/synfig/synfig/commit … 141b1f5d9c )
I think it’s best to use precompiled portable build of python in this case: portablepython.com/wiki/Download
Cheers!
meh - for some reason, although I’ve compiled and installed version 0.50.2 of intltools, it doesn’t seem to be recognized.
I’ll try again on Thursday.
What is the step it fails on? ./bootstrap.sh?
no, that step works. It’s the configure that fails.
Looks like intltool is not found…
Googling suggest me this: forum.compiz.org/viewtopic.php?p … d6d#p35871
Check the path where intlotool got installed.
Also, try to play with ACLOCAL_FLAGS variable - sites.google.com/site/chrelad/n … localflags
I moved the intltool.m4 file over and now I get cnorman@VXP ~/synfig
$ ./configure_studio.sh
Configuring
/usr/share/aclocal/autoopts.m4:22: warning: underquoted definition of AG_PATH_AUTOOPTS
run info '(automake)Extending aclocal'
or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal
Putting files in AC_CONFIG_AUX_DIR, `config'.
/usr/share/aclocal/autoopts.m4:22: warning: underquoted definition of AG_PATH_AUTOOPTS
run info '(automake)Extending aclocal'
or see http://sources.redhat.com/automake/automake.html#Extending%20aclocal
configure:468: error: possibly undefined macro: AM_DEFAULT_VERBOSITY
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
autoreconf: /usr/bin/autoconf failed with exit status: 1
One step closer (?)
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.
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?
Hi, Pixelgeek!
Attaching full list of library versions used for OSX build.
I hope that help.
K.
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 )
Good sign …
go Pixelgeek go!!
-G
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'.
./configure_core.sh: /bin/autoreconf: /bin/perl: bad interpreter: No such file or directory
more googling[code]
2008-06-06 Tor Lillqvist
* intltool-update.in (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
line.
(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.)
[/code]
Fix up Perl path in autoreconf
Configuring
Can't locate Autom4te/ChannelDefs.pm 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>
*/
mingw.5.n7.nabble.com/Posix-supp … 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