Hi,
Andreas, (and /usr/local savvy guys!)
Well, I hope somebody else knows more ... :-)
Please tell me how things have gone. Basically I'm waiting for these issues to be solved to make the 0.7.2 release.
With the current version it does no longer work *quite* out of the box on the BSD's. It will work when doing a CPPFLAGS=/usr/local/include LDFLAGS=/usr/local/lib ./configure but this is not what I call out of the box :-).
I'm not an expert in tunning the system's directories, but I wonder why if /usr/local has part of the system, it is not included in the search path in BSDs. Doesn't make sense to me (nut I don't know much here).
All right, in terms of reasoning and well thought systems, I prefer OpenBSD, hence I did a google search and came across this lengthy discussion : http://www.netsys.com/openbsd-tech/1996/02/msg00019.html and follow-ups !!!! But other than that ....
OTOH, for instance, /usr/local is not a part of the system in Slackware, and I can't find it with: `gcc -print-search-dirs`.
Actually, I think gcc -print-search-dirs is not the way to find out about the inclusion of /usr/local - it doesn't show on any system I have. Try cpp -v </dev/null instead. In fact, I think, that should be used in the test instead of what I submitted earlier ... oh well ;-) I just tested ---- start patch ---- $ cvs diff -c configure.in cvs diff: failed to open /home/darkstar/andy/.cvspass for reading: No such file or directory Index: configure.in =================================================================== RCS file: /sfhome/cvs/dillo/dillo/configure.in,v retrieving revision 1.49 diff -c -r1.49 configure.in *** configure.in 10 Apr 2003 20:12:44 -0000 1.49 --- configure.in 10 Apr 2003 23:47:08 -0000 *************** *** 28,33 **** --- 28,38 ---- AC_PROG_CC AM_PROG_CC_STDC AC_PROG_RANLIB + AC_PROG_CPP + if test ! "`$CPP -v < /dev/null 2>&1 | grep '/usr/local/include'`" ; then + CPPFLAGS="$CPPFLAGS -I/usr/local/include" + LDFLAGS="$LDFLAGS -L/usr/local/lib" + fi dnl ----------------------------------- dnl Check for Gtk+ (it checks glib too) ---- end patch ---- to work correctly so far. I hope that patch in the middle of the e-mail is ok ...
Doubts started when I received this mail, from Manuel Menal: [mmenal at hurdfr.org]
<snip>
output. If there is some output, then it assumes there is no jpeglib.h. Which is not true in this case: the output is just warning of cpp, which complains about the -I/usr/local/include (cpp 3.1 already has /usr/local/include it its system directories).
I think the problem there is a mixup of stdout and stderr. On one Linux system (Suse), I do get the warning, but it still detects jpeglib.h Another system does include /usr/local by default, as well (Archlinux), but does not give any warning in config.log .... beats me.
Thinking that /usr/local was for extensions, I decided to remove the forced include from configure.in.
Can anyone shed some light on this topic?
Not more that my google results from above. Personally, I think we should indeed check if /usr/local is in the gcc definition or not and react accordingly.
The png.h stuff is more or less my original solution :-) ... there was a reason for that convoluted approach ... :-)
Yes, I added the break clause because it tested libpng twice and added two "-lpng" in my system.
I'll commit the patch as you sent here (which BTW, includes the "break").
Yes, I did leave the "break" intentionally ! I just wasn't quite clear about the usage of "break". BTW, in my previous mail I promised to test on OpenBSD : success. Cheers Andreas -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198