This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: Resolving libc #includes
- From: Earl Chew <earl_chew at agilent dot com>
- To: Roland McGrath <roland at redhat dot com>
- Cc: libc-alpha at sources dot redhat dot com
- Date: Mon, 15 Nov 2004 14:26:03 -0800
- Subject: Re: Resolving libc #includes
- References: <200411152206.iAFM60LN012758@magilla.sf.frob.com>
Roland McGrath wrote:
If you are using -I options you are getting what you asked for.
If not, that's why #include <...> or different from #include "...".
Say I use:
% cat foo.c
...
#include <stdio.h>
...
% gcc -I application/includes -c foo.c
and I happen to have a file named application/includes/features.h.
If I understand you correctly, you're saying that it's expected
behaviour when an error results as the application uses
#include <stdio.h> to use stdio from libc, and the compile fails
because the compiler feeds application/include/features.h to libc.
I think you're tell me that the application should:
a. Rename application/includes/features.h to something else that
doesn't collide with the library, or
b. Not use -I in the compiler invocation.
I do not believe there is anything in the standard precluding
an application from naming an application header features.h,
and I also do not know of any rule an application can follow
to stay clear of potential file naming conflicts with libc.
I think abstaining from -I a little impractical.
Earl