[elinks-users] renderer.c:1685: error: 'struct cache_entry' has no member named 'cache_mode' when compiling eLinks v0.11.3 in Debian (PowerPC)
Kalle Olavi Niemitalo
kon at iki.fi
Sun Jul 1 13:22:22 PDT 2007
In almost all of your build logs
http://www.savefile.com/files/854658 (configs.zip; no build log)
http://www.savefile.com/files/854708 (configs2.zip; no build log)
there is this section:
404. cd ./. && autoheader
405. configure.in:41: warning: Cannot check for file existence when cross compiling
406. configure.in:42: warning: Cannot check for file existence when cross compiling
407. cd . \
408. && CONFIG_FILES= CONFIG_HEADERS=config.h \
409. /bin/sh ./config.status
410. config.status: creating config.h
i.e. configure.in is being converted to a new config.h.in, and
that then to config.h. The generated config.h.in and config.h do
not include the all-important HAVE_SYS_TIME_H reference.
However, in http://www.savefile.com/files/854658 (configs.zip),
config.h does define HAVE_SYS_TIME_H. Did you by chance save
that config.h after running configure but before running make?
The config.h.in file is supposed to be generated by ELinks
developers, using a known compatible version of autoheader, and
included in elinks-*.tar.gz; users should then use the included
version of config.h.in and not rerun autoheader. In your case
however, Makefile is deciding to run autoheader. The bug appears
to be that elinks-0.11.3.tar.gz does not include the stamp-h.in
file. It was included in ELinks 0.10.6 but lost in 0.11.0.
To work around the bug:
- Extract elinks sources to a fresh directory, so that you get
the included version of config.h.in.
- Create a stamp-h.in file in the directory where config.h.in is.
The contents of stamp-h.in do not matter but the file must exist
and have a newer timestamp than configure.in and aclocal.m4.
- Then run configure and make. Now, make should not run autoheader.
Please confirm whether this workaround helps, and I'll then add
it to bug 936. We should also revise the packaging process so
that stamp-h.in gets properly included, or change the Makefile;
and update the AC_PREREQ so that any attempt to use an incompatible
version of autoheader results in an obvious error.
I have been unable to reproduce bug 936 previously because I of
course have a compatible version of autoheader installed.
More information about the elinks-users