Hi,
> On Sun, 28 Jan 2007, Guenter Knauf wrote:

> There are many kinds of systems/compilers. I'm not the one to dictate
> rules
> for each on how to generate/create the ca-bundle.h file or the define it
> contains, and I'm fine with it being done in whatever way.
good.

> Oops, indeed a correct observation. That's a bug, and I fixed it.
yep, seen...

> 1 - Removing the include would work for me, but I remember having problems
> with getting the path properly generated in lib/config.h by configure
> which I
> believe was the reason I created the ca-bundle.h file in the first place.

> If you can make configure create it in lib/config.h, I would be totally ok
> with that.
ok, will do my best and look into that; but will wait with that after you have released since Linux works fine currently as is.

> 2 - Why would we want libcurl to get the system's cacert bundle from an
> environment variable? Is there any application you know of that would
> benefit
>>from this? curl already does this kind of magic on its own and thus
>>wouldn't.
good question - but then let me ask why you want to put the hardcoded path on Linux at same place?
I did what probably most if not all developers did when they ported to a new non-configure platform: I tried to compile, and it broke in url.c because of missing ca-bundle.h; then I grep'd through the sources, and found that others already used the define, and took that since it looked good....
I did not care about what really happened with that define cause it was there before I started on cURL...

anyway, what's currently in the mingw Makefile works only when compiled with MSYS bash shell, but fails when cmd.exe or command.com is the shell, and leads to a segfault.
So I take your first comment as permission to fix it for all Win32 builds the way I proposed it, and after release I will look closer into removing the ca-bundle.h entirely....

thanks, Guen.
Received on 2007-01-29