On Sat, 31 Jan 2004, Domenico Andreoli wrote:

> it seems that this bug has been introduced between release 1.75 and 1.76 of
> lib/ca-bundle.h for the same reason i consider it a bug.

lib/ca-bundle.h has no version number, it is generated. Or were you referring
to the lib/Makefile.am version?

> IMHO it is not so clean to assume a particular search order of the include
> paths, unless you impose it (i did not look who is choosing the order here).

Actually, we don't assume a search order, we have it set fine in the Makefile.
The problem here is that previously we generated the new ca-bundle.h in the
source dir instead of in the build dir, and I recently fixed this bad
behavior.

What I didn't fix was the include line in url.c, see patch below.

Proven here, we don't have any test cases that verify the cacert
functionality. I'm hoping Peter Sylvester's upcoming work on the test suite
will address this shortcoming.

> simply removing srcdir/lib/ca-bundle.h solved my problem. why this file is
> distirbuted? it is useless and it gets updated since the first build.

It is useless on all *nix machines. It is not useless on a lot of other
machines.

Patch:

diff -u -u -r1.331 url.c
--- url.c 26 Jan 2004 16:16:44 -0000 1.331
+++ url.c 2 Feb 2004 10:07:14 -0000
@@ -116,7 +116,7 @@
 #include "ldap.h"
 #include "url.h"
 #include "connect.h"
-#include "ca-bundle.h"
+#include <ca-bundle.h>

 #include <curl/types.h>

-- 
    Daniel Stenberg -- http://curl.haxx.se/ -- http://daniel.haxx.se/
   [[ Do not send mails to this email address. They won't reach me. ]]
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn