Anyone know why moocow is dying on Fedora with this error:
http://autobuild.puredata.info/auto-build/2008-11-16/logs/ 2008-11-16_04.30.20_linux_fedora8-i386_pd-extended_run-automated- builder.txt
gcc -DHAVE_CONFIG_H -I. -I. -DPIC -O3 -pipe -fPIC -Wall -DPD -O2 - mtune=i686 -march=i386 -ftree-vectorize -ftree-vectorizer-verbose=3 - I/home/pd/auto-build/pd-extended/pd/src -Wall -W -ggdb -I/home/pd/ auto-build/pd-extended/Gem/src -I/home/pd/auto-build/pd-extended/ externals/pdp/include -DUNIX -Dunix -fPIC -c atom_alphabet.c In file included from atom_alphabet.c:28: ./atom_alphabet.h:32:18: error: gfsm.h: No such file or directory In file included from atom_alphabet.c:28: ./atom_alphabet.h:39: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'pd_atom_alphabet_methods' ./atom_alphabet.h:45: error: expected specifier-qualifier-list before 'gfsmUserAlphabet' ./atom_alphabet.h:54: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'gfsm_pd_atom_hash' ./atom_alphabet.h:57: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'gfsm_pd_atom_equal' ./atom_alphabet.h:66: error: expected declaration specifiers or '...' before 'GString' ./atom_alphabet.h:69: error: expected declaration specifiers or '...' before 'GString' atom_alphabet.c:34: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'pd_atom_alphabet_methods' atom_alphabet.c:52: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'gfsm_pd_atom_hash' atom_alphabet.c:68: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'gfsm_pd_atom_equal' atom_alphabet.c: In function 'gfsm_pd_atom_dup':
.hc
------------------------------------------------------------------------ ----
Using ReBirth is like trying to play an 808 with a long stick. - David Zicarelli
morning Hans, morning list,
On 2008-11-18 02:32:57, Hans-Christoph Steiner hans@eds.org appears to have written:
Anyone know why moocow is dying on Fedora with this error:
http://autobuild.puredata.info/auto-build/2008-11-16/logs/ 2008-11-16_04.30.20_linux_fedora8-i386_pd-extended_run-automated- builder.txt
gcc -DHAVE_CONFIG_H -I. -I. -DPIC -O3 -pipe -fPIC -Wall -DPD -O2 - mtune=i686 -march=i386 -ftree-vectorize -ftree-vectorizer-verbose=3 - I/home/pd/auto-build/pd-extended/pd/src -Wall -W -ggdb -I/home/pd/ auto-build/pd-extended/Gem/src -I/home/pd/auto-build/pd-extended/ externals/pdp/include -DUNIX -Dunix -fPIC -c atom_alphabet.c In file included from atom_alphabet.c:28: ./atom_alphabet.h:32:18: error: gfsm.h: No such file or directory
[snip]
Looks like libgfsm isn't installed on the build machine.
See here (lines 17359-17361):
gcc -DHAVE_CONFIG_H [...] -c atom_alphabet.c In file included from atom_alphabet.c:28: ./atom_alphabet.h:32:18: error: gfsm.h: No such file or directory
See also line 17313 (output of the preceeding call of `sh moocow/gfsm/configure`):
checking for GFSM... no configure: WARNING: configure: WARNING: ---------------------------------------------------------------- configure: WARNING: gfsm library not found! configure: WARNING: configure: WARNING: Is the directory containing gfsm.pc in your configure: WARNING: 'PKG_CONFIG_PATH' environment variable? configure: WARNING: ---------------------------------------------------------------- configure: WARNING:
... and the echo of the actual "failing" build command as invoked by moocow/extended/Makefile (make[3]) at line 17348:
make DESTDIR="" -C ../gfsm all install || true
... also note that after the "failed" build of the gfsm externals, the dummy target "moocow/extended/gfsm.build_stamp" *does* in fact get successfully created (lines 17411-17419):
make[7]: *** [atom_alphabet.o] Error 1 make[7]: Leaving directory `/home/pd/auto-build/pd-extended/externals/moocow/gfsm/src' make[6]: *** [all-recursive] Error 1 make[6]: Leaving directory `/home/pd/auto-build/pd-extended/externals/moocow/gfsm/src' make[5]: *** [all] Error 2 make[5]: Leaving directory `/home/pd/auto-build/pd-extended/externals/moocow/gfsm/src' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/home/pd/auto-build/pd-extended/externals/moocow/gfsm' touch gfsm.build_stamp
... and the build process continues (without crashing) ...
... so aside from the (admittedly ugly, but otherwise inconsequential for the rest of the build process) errors, what's the problem? I could take the gfsm externals out of the list of 'moocow' build targets for pd-extended (since libgfsm isn't likely to be installed anywhere but on my own machines), but it ought to build successfully whenever libgfsm is installed, and it is freely available (LGPL, from me: http://www.ling.uni-potsdam.de/~moocow/projects/gfsm). I suppose I could also pack a local version of libgfsm into pd-gfsm and build it with the externals, or move it to sourceforge and use svn:externals, etc. etc. ... but that all seems like overkill to me... anyone have an opinion?
marmosets, Bryan
On Nov 18, 2008, at 5:09 AM, Bryan Jurish wrote:
morning Hans, morning list,
On 2008-11-18 02:32:57, Hans-Christoph Steiner hans@eds.org appears to have written:
Anyone know why moocow is dying on Fedora with this error:
http://autobuild.puredata.info/auto-build/2008-11-16/logs/ 2008-11-16_04.30.20_linux_fedora8-i386_pd-extended_run-automated- builder.txt
gcc -DHAVE_CONFIG_H -I. -I. -DPIC -O3 -pipe -fPIC -Wall -DPD -O2 - mtune=i686 -march=i386 -ftree-vectorize -ftree-vectorizer-verbose=3 - I/home/pd/auto-build/pd-extended/pd/src -Wall -W -ggdb -I/home/pd/ auto-build/pd-extended/Gem/src -I/home/pd/auto-build/pd-extended/ externals/pdp/include -DUNIX -Dunix -fPIC -c atom_alphabet.c In file included from atom_alphabet.c:28: ./atom_alphabet.h:32:18: error: gfsm.h: No such file or directory
[snip]
Looks like libgfsm isn't installed on the build machine.
See here (lines 17359-17361):
gcc -DHAVE_CONFIG_H [...] -c atom_alphabet.c In file included from atom_alphabet.c:28: ./atom_alphabet.h:32:18: error: gfsm.h: No such file or directory
See also line 17313 (output of the preceeding call of `sh moocow/gfsm/configure`):
checking for GFSM... no configure: WARNING: configure: WARNING:
configure: WARNING: gfsm library not found! configure: WARNING: configure: WARNING: Is the directory containing gfsm.pc in your configure: WARNING: 'PKG_CONFIG_PATH' environment variable? configure: WARNING:
configure: WARNING:
... and the echo of the actual "failing" build command as invoked by moocow/extended/Makefile (make[3]) at line 17348:
make DESTDIR="" -C ../gfsm all install || true
... also note that after the "failed" build of the gfsm externals, the dummy target "moocow/extended/gfsm.build_stamp" *does* in fact get successfully created (lines 17411-17419):
make[7]: *** [atom_alphabet.o] Error 1 make[7]: Leaving directory `/home/pd/auto-build/pd-extended/ externals/moocow/gfsm/src' make[6]: *** [all-recursive] Error 1 make[6]: Leaving directory `/home/pd/auto-build/pd-extended/ externals/moocow/gfsm/src' make[5]: *** [all] Error 2 make[5]: Leaving directory `/home/pd/auto-build/pd-extended/ externals/moocow/gfsm/src' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/home/pd/auto-build/pd-extended/ externals/moocow/gfsm' touch gfsm.build_stamp
... and the build process continues (without crashing) ...
... so aside from the (admittedly ugly, but otherwise inconsequential for the rest of the build process) errors, what's the problem? I could take the gfsm externals out of the list of 'moocow' build targets for pd-extended (since libgfsm isn't likely to be installed anywhere but on my own machines), but it ought to build successfully whenever libgfsm is installed, and it is freely available (LGPL, from me: http://www.ling.uni-potsdam.de/~moocow/projects/gfsm). I suppose I could also pack a local version of libgfsm into pd-gfsm and build it with the externals, or move it to sourceforge and use svn:externals, etc. etc. ... but that all seems like overkill to me... anyone have an opinion?
Hey,
Since libgfsm isn't included in any package management systems that I checked (Debian, Ubuntu, Fedora, Fink), I think it makes sense to include the libgfsm code in the pure-data SVN.
The weird thing is that AFAIK, libgfsm is not installed on any of the build farm machines, but this error only seems to happen on the Fedora 8 machine.
.hc
marmosets, Bryan
-- Bryan Jurish "There is *always* one more bug." jurish@ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology
------------------------------------------------------------------------ ----
Mistrust authority - promote decentralization. - the hacker ethic
morning Hans, morning list,
On 2008-11-18 21:18:41, Hans-Christoph Steiner hans@eds.org appears to have written:
On Nov 18, 2008, at 5:09 AM, Bryan Jurish wrote:
On 2008-11-18 02:32:57, Hans-Christoph Steiner hans@eds.org appears to have written:
Anyone know why moocow is dying on Fedora with this error: gcc -DHAVE_CONFIG_H [...] -c atom_alphabet.c In file included from atom_alphabet.c:28: ./atom_alphabet.h:32:18: error: gfsm.h: No such file or directory
... and the build process continues (without crashing) ...
... so aside from the (admittedly ugly, but otherwise inconsequential for the rest of the build process) errors, what's the problem? I could take the gfsm externals out of the list of 'moocow' build targets for pd-extended (since libgfsm isn't likely to be installed anywhere but on my own machines), but it ought to build successfully whenever libgfsm is installed, and it is freely available (LGPL, from me: http://www.ling.uni-potsdam.de/~moocow/projects/gfsm). I suppose I could also pack a local version of libgfsm into pd-gfsm and build it with the externals, or move it to sourceforge and use svn:externals, etc. etc. ... but that all seems like overkill to me... anyone have an opinion?
Hey,
Since libgfsm isn't included in any package management systems that I checked (Debian, Ubuntu, Fedora, Fink), I think it makes sense to include the libgfsm code in the pure-data SVN.
The weird thing is that AFAIK, libgfsm is not installed on any of the build farm machines, but this error only seems to happen on the Fedora 8 machine.
nope. same stuff happens elsewhere too, e.g. i386-debian-stable (http://autobuild.puredata.info/auto-build/2008-11-16/logs/2008-11-16_01.49.3...) line 17342:
gcc -DHAVE_CONFIG_H [...] -c atom_alphabet.c In file included from atom_alphabet.c:28: ./atom_alphabet.h:32:18: error: gfsm.h: No such file or directory
I'll want to experiment a bit with recursive autoconf/automake stuff before I can include libgfsm in the pd svn, but all things considered, I think you're right and that's the best solution for the time being. Optimally, pd-gfsm would always use its own version of libgfsm, to insulate against unforseen gfsm API changes... hmm...
marmosets, Bryan
-
Bryan Jurish -
Hans-Christoph Steiner