On Wed, Dec 17, 2008 at 05:01:26PM +0000, Thorsten Glaser wrote: > Dixi quod… > > >This is fun, I get this with 2.8.7dev.11a (but not dev.8): > > > >[…] > >checking if SIGWINCH is defined... yes > >checking if you want NSS compatible SSL libraries... no > >checking if you want ssl library... /usr > >checking if you want gnutls support... no > >checking if you want gnutls-openssl compat... no > >checking if you want socks library... no > >[…] > > Can be fixed with two changes: > > • export ac_cv_path_PKG_CONFIG=none into the configure environment > ‣ it seems to try to still use an installed pkg-config from ports > while compiling for base; pkg-config is undesirable anyway even > for ports because it “automagically” picks up stuff it finds in- > stead of having proper dependency handling
I hadn't thought about the problem of pkg-config in ports (though now that I'm reminded, it's "of course" - though the script is supposed to recover if the openssl library isn't known to pkg-config). Like anything else, it's easy to make it optional. Whether to make it look for pkg-config by default or not is debatable. Since the reason for adding it was to address the users who have trouble setting up stray environment variables, it seems that making it the default is the way to go... > • replace 「--with-ssl=/usr」 with 「--with-ssl」 > ‣ apparently, the argument to --with-ssl is assigned to a variable > which is thusly tristate (no, yes, somepath), but at least one > of the CF_SSL checks thinks it’s boolean, checks only for equality > with ‘yes’ (instead of diverging from ‘no’) and fails if a path > is given yes, it's tristate (has been, since it was implemented). From your comment, I see there's someplace in the logic that was broken by weaving in the support for pkg-config -- Thomas E. Dickey <[email protected]> http://invisible-island.net ftp://invisible-island.net _______________________________________________ Lynx-dev mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lynx-dev
