cURL / Mailing Lists / curl-library / Single Mail


Re: lcc-win32 patches

From: Gisle Vanem <>
Date: Tue, 1 Jun 2004 13:40:11 +0200

"Daniel Stenberg" <> said:

> So I guess the question is: is it worth changing this to better support lcc
> builds, or can the lcc build be modified slightly to better support the
> current setup (assuming that lcc will fix this flaw at some point)?

>From libcurl's lib directory; gcc -v $(CFLAGS) base64.c:
#include "..." search starts here:
#include <...> search starts here:

So "../include/curl" isn't in the search path, but gcc "magically" finds
"../include/curl/easy.h" refered in "../include/curl/curl.h". gcc/cpp uses
the rule; "add the directory of current file as the 1st search directory for
#include "file". So you're right; another "easy.h" shouldn't be pixed up
from somewhere else.

I wouldn't say lcc is wrong. It just doesn't implement this magic as the
ANSI std requires (?). But it can be fixed by adding -I../include/curl/curl.

BTW. Using "-I-" with gcc (split the include path). E.g.
gcc -I- -I. -I../include, will also fail to find "curlver.h", "easy.h" etc.


I'm not sure when "-I-" would be handy, but sure there is a use for it.

Received on 2004-06-01