Re: configuration patch - Fix for bugs 386, 407, 392, 412 and notes on bugs 349, 408
Andreas,
I just commited a minor change to the new configure.in. It avoids running AC_CHECK_LIB twice when testing png headers. I hope it is the right thing to do! :)
I'll check it out and test it on a bunch of systems. The testing will probably take a while, but I won't be able to do it on the weekend :-) *Maybe* before.
Please tell me how things have gone. Basically I'm waiting for these issues to be solved to make the 0.7.2 release. Has anyone else tested the changes this mail's subject alludes? Cheers Jorge.-
Hi,
I just commited a minor change to the new configure.in. It avoids running AC_CHECK_LIB twice when testing png headers. I hope it is the right thing to do! :)
Well, sort of. See below.
I'll check it out and test it on a bunch of systems. The testing will probably take a while, but I won't be able to do it on the weekend :-) *Maybe* before.
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 :-). Also, if png.h is on libpng/png.h and NOT as well in png.h, it will complain, it does not find png.h. However, this warning is misleading, since configure will find everything just fine and dillo compiles and works just fine. I attach a patch which fixes both problems. The /usr/local stuff really only is an issue for gcc3.x since gcc3.x already has /usr/local as default directories, so I test for that case. That *should* be ok. The png.h stuff is more or less my original solution :-) ... there was a reason for that convoluted approach ... :-)
Has anyone else tested the changes this mail's subject alludes?
Yes, please, so far I tested on FreeBSD 4.7 with gcc2.95 and some Linux variants. I'll test OpenBSD later (but that should be ok ...). But if somebody has some other systems, do test ! FreeBSD 5.0 anyone ? Cheers Andreas P.S.: "full-screen" may indeed be misleading - maybe all of us got used to what it means :-) -- **************************** NEW ADDRESS ****************************** Hamburger Sternwarte Universitaet Hamburg Gojenbergsweg 112 Tel. ++49 40 42891 4016 D-21029 Hamburg, Germany Fax. ++49 40 42891 4198
Andreas, (and /usr/local savvy guys!)
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). 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`. Doubts started when I received this mail, from Manuel Menal: [mmenal at hurdfr.org] <q> Hey, While porting Dillo to the new implementation of POSIX threads for GNU/Hurd (code name: "Rubbish, I asked for mine with Minced Garlic, Please Take this back"), I found some minor bugs in the Dillo "installation system". The first bug I found out was a bug that was already reported as #349 in the Dillo bug report system. It seems a quite simple and not so annoying bug, but in fact it is quite pervert, as it makes the configure misdetect what is installed in the system: when it checks for jpeglib.h (& others), it tries to preprocess a simple C file which only includes jpeglib.h, and check if there is some 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). [...] </q> 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?
Also, if png.h is on libpng/png.h and NOT as well in png.h, it will complain, it does not find png.h. However, this warning is misleading, since configure will find everything just fine and dillo compiles and works just fine.
I understand.
I attach a patch which fixes both problems.
The /usr/local stuff really only is an issue for gcc3.x since gcc3.x already has /usr/local as default directories, so I test for that case. That *should* be ok.
(explained above)
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"). Cheers Jorge.-
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
Andreas,
[...] 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 !!!!
Well, from there, it becomes clear that this is not an easy to solve problem...
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 ----
Commited!
<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.
The /usr/local test should solve the problem, as the compiler complained about the forced inclusion (and order change) of the system's directories.
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.
Well, the conditional inclusion (CPP test) is our default way now! I hope it works; at least is passes a lot of tests. Now is time to finish the last details for the 0.7.2 release! Cheers Jorge.-
participants (2)
-
Andreas Schweitzer -
Jorge Arellano Cid