Blake Barnett <[EMAIL PROTECTED]> writes: > I work on the enlightenment project and this occurs when build any of > their packages. A specific example of the problem is in the Embryo > library: > http://e.kevb.net/cgi-bin/viewcvs.cgi/e17/libs/embryo/configure.in? > rev=1.37&content-type=text/vnd.viewcvs-markup
I tried to investigate by downloading and installing a snapshot of "eet", which contains similar code in its configure.in and which http://enlightenment.freedesktop.org/ says is a prerequisite for embryo, or at least should be compiled first. It compiled the same way with both the configure script that was included and the one that I regenerated with Debian 2.59.cvs.2006.05.13-1. The "make -n install" output was identical from both. The "configure" script from the CVS autoconf did report warnings for the lack of datarootdir. This appears to be harmless. The two versions of "configure" generated identical config.h, modulo a few comments. They also generated mostly identical Makefile.in, except for a few worrisome parts that appear unrelated to your bug report: -ac_ct_AR = ar +ac_ct_AR = @ac_ct_AR@ +ac_ct_RANLIB = @ac_ct_RANLIB@ +ac_ct_STRIP = @ac_ct_STRIP@ (Looks like some substitutions are missing somehow. Perhaps I need to run more than just "autoconf".) So: can you be more specific about what the bug actually is? As far as I can tell, it configures, builds, and installs the same way with both versions of Autoconf. The CVS version does report a warning from config.status; is the warning what you're reporting as a bug? I took a look at the configure.in itself in this package. What is it actually trying to do? It is full of so much bizarre cut-and-paste weirdness that I lose the thread of what's going on. Example: if test "x${bindir}" = 'x${exec_prefix}/bin'; then if test "x${exec_prefix}" = "xNONE"; then if test "x${prefix}" = "xNONE"; then bindir="${ac_default_prefix}/bin"; else bindir="${prefix}/bin"; fi else if test "x${prefix}" = "xNONE"; then bindir="${ac_default_prefix}/bin"; else bindir="${prefix}/bin"; fi fi fi The two forks of the middle test (test "x${exec_prefix}" = "xNONE") contain exactly the same code. At least, I stared at both of them for a long time and couldn't see any difference. And then there's a similar block of code that does the same thing for libdir. -- "It was then I realized how dire my medical situation was. Here I was, a network admin, unable to leave, and here was someone with a broken network. And they didn't ask me to fix it. They didn't even try to casually pry a hint out of me." --Ryan Tucker in the Monastery
