Hi there! We're trying to fix our configure.in with Andreas. The latest CVS commit has a boat load of minor changes that require testing. Please refer to the subject line for BUG# numbers. On Sun, 23 Mar 2003, Andreas Schweitzer wrote:

Hi Jorge,

This patch - mainly against configure.in - fixes all these bugs - some of which are duplicates, actually.

Sure.

The startegy I implemented is : First check the headers, if not found return a big warning and don't bother anything else. If found, check how to link (that *should* work now). That last test puts some nice HAVE_LIBPNG etc. in config.h, but only if I don't fool with the "ACTION-IF-FOUND" and "ACTION-IF-NOT-FOUND" fields.

It is suggested to first check the headers and then the libraries, but every time I get into autoconf/automake I get a bad gut sensation. It is so confuse and messy... I checked the new code and decided to give more order to the whole stuff in there. This means some things changed, but the tests for jpeg and png remained (with some changes for zlib).

About libpng : Since version 1.2.2 it moved the headers to libpng/png.h which is correct on all platforms I tested. Since version 1.2.3 the install *should* create a link to the old location, and there *should* be a libpng-config script. Both these "shoulds" are only partially implemented depending on platform/system. sigh. But my libpng test should now find the header. See also http://www.libpng.org/pub/png/png2002.html

I added just a minor change. Hope it works!

The location of the system dillorc should NOT be put in config.h according to the GNU docs, instead everything with prefix/sysconfdir and similar stuff should be defined on the command line. Hence, my src/Makefile.am patch. This syntax of ' and " works on a variety of systems (bash, ksh, csh, GNU make) finally. Also, the current toplevel Makefile.am first tries $(DESTDIR)$(sysconfdir) and then falls back on /etc but the code in prefs.c does it the other way round. One of them should probably be reverted. And while writing this : the patch supplied on the list will make dillorc be installed ONLY in $(DESTDIR)$(sysconfdir) with no fall-back to /etc but I think $(DESTDIR)$(sysconfdir) will be created if necessary.

I'm not sure of what to do here :(. For now I added Patrice's patch that simply adds: sysconf_DATA = dillorc in Makefile.am, and it works! The problem is we don't know what directory it gets in. :-) Currently if it is /usr/local/etc/ or /etc, it works, but if someone chooses /opt/weird/etc, it won't be found. If your solution fixes this, I'll switch to it.

About 349 : not sure if this really causes trouble. I may have to do some major autoconf thing - like trying with default and then trying with /usr/local added - for each test, though (maybe a new macro ?).

I removed the /usr/local stuff: -CPPFLAGS="$CPPFLAGS -I/usr/local/include" -LDFLAGS="$LDFLAGS -L/usr/local/lib" IMHO, it shouldn't be there, as the system SHOULD be configured in a way that programs are able to find system resources. Maybe this serves as a workaround: CPPFLAGS="$CPPFLAGS -I/usr/local/include" ./configure :-)

About 408: this seems to be caused by using libpng 1.0.12 (i.e. the old libpng). On Debian it seems to be called that strangly. The person should probably give more details or use libpng 1.2.X.

Yes, that seems to be caused by an ancient libpng. We should give a warning.

Tested on OpenBSD 3.2 (gcc 2.95, autoconf2.13, automake1.4) FreeBSD 4.7 (gcc 2.95, autoconf2.13, automake1.4) Linux 2.4.20 (gcc 3.2, autoconf2.57, automake1.7)

Well, now without the forced "/usr/local/..." stuff, is different. I only hope we find the way to fix our configure stuff the right way...

To test it, it probably needs to go on a lot more platforms but I hesitated to send it to the list. Feel free to forward this mail as is to the list.

I'm doing it right now!!! ...and the CVS has the new version. All the helpful feedback is very welcomed! Cheers Jorge.- PS: Get a new copy from CVS, ./autogen.sh, ./configure ...