Re: lcc-win32 patches
Date: Tue, 1 Jun 2004 13:40:11 +0200
"Daniel Stenberg" <daniel-curl_at_haxx.se> 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