hashdist / hashstack-old

Obsolete repository, use "hashstack" instead
3 stars 4 forks source link

m4 fails to build on ubuntu 13.04 #81

Closed cekees closed 11 years ago

cekees commented 11 years ago

[m4] In file included from clean-temp.h:22:0, [m4] from clean-temp.c:23: [m4] ./stdio.h:477:1: error: 'gets' undeclared here (not in a function) [m4] make[3]: * [clean-temp.o] Error 1 [m4] make[2]: * [all] Error 2 [m4] make[1]: * [all-recursive] Error 1 [m4] make[3]: Leaving directory /home/cekees/hashstack/bld/m4-n-3rp5/src/lib' [m4] make[2]: Leaving directory/home/cekees/hashstack/bld/m4-n-3rp5/src/lib' [m4] make[1]: Leaving directory `/home/cekees/hashstack/bld/m4-n-3rp5/src' [m4] make: * [all] Error 2 [m4 ERROR] Command '['make']' returned non-zero exit status 2 [m4 ERROR] command failed (code=2); raising $

cekees commented 11 years ago

seems to be an issue with an old stdio.h included with the m4 source. I've tried building the develoment source of m4 and the save version as we use but have not had any success.

certik commented 11 years ago

This m4 is only needed for setting up autotools, which unfortunately are needed for the "mesa" package, and also for the "patchelf", which we need to install from git, because the upstream tarball is hosted on a server which is sometimes down. One solution is to create proper configure script for mesa / patchelf and then just host our own tarballs somewhere. That way we can avoid having autotools completely.

But on the other hand, I think we also want hashdist to be used for development, and some projects simply use autotools --- and so you need it if you want to develop it. So I think a better solution is to figure out how to build m4, if it is not such a big pain.

certik commented 11 years ago

Ok, so according to this link:

http://comments.gmane.org/gmane.comp.gnu.m4.bugs/3055

this is a genuine bug in M4 1.4.16, which is the one we currently use. The solution is to update to 1.4.17 --- which actually hasn't been released yet, so either we need to use the git version, or rather apply this one line patch:

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-devel/m4/files/m4-1.4.16-no-gets.patch

to the version that we have.

cekees commented 11 years ago

I was not able to find 1.4.17 anywhere, but I did verify that we can build the 'branch-1.4' branch from the m4 git repository on my ubuntu machine. You have to run a bootstrap script that that also installs gnulib before generating the configure script, which requires help2man and texinfo. I don't know if we could make a tarball out of the result of the running 'make distclean' or not.

On Thu, Jun 20, 2013 at 1:24 PM, Ondřej Čertík notifications@github.comwrote:

Ok, so according to this link:

http://comments.gmane.org/gmane.comp.gnu.m4.bugs/3055

this is a genuine bug in M4 1.4.16, which is the one we currently use. The solution is to update to 1.4.17. The other option is to apply this patch:

http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/sys-devel/m4/files/m4-1.4.16-no-gets.patch

to the version that we have.

— Reply to this email directly or view it on GitHubhttps://github.com/hashdist/python-hpcmp2/issues/81#issuecomment-19773328 .

certik commented 11 years ago

(The 1.4.17 is not released yet, I have updated my comment above.)

The patch f6be2a58de62327d05e052d89c9aa931d4c926b3 fixes this issue.