This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Error report (gcc 3.1)


Nix <nix@esperi.demon.co.uk> writes:

| On Thu, 16 May 2002, Gabriel Dos Reis stated:
| > Jakub Jelinek <jakub@redhat.com> writes:
| > 
| >| On Thu, May 16, 2002 at 11:33:14PM +0200, Gabriel Dos Reis wrote:
| >| > Aha, thanks.  But as I said in another message, people expect to find
| >| > header files under ${prefix}/include.  We shouldn't depart from that.
| >| 
| >| Headers like <stddef.h>, <limits.h> etc. are already there, likewise all
| >| fixincluded headers.
| > 
| > Those headers come from GCC washing some system headers and kept there
| > for distinguishing them from natives.  Normal users or tools are not
| > expected to look for them there.  That is our existing practice.  Our
| > existing practice is also following the expectation that header files
| > are under ${prefix}/include or anyplace explicitly set at
| > configuration time.
| 
| Kludge suggestion: why not put the headers in the versioned location,
| but put symlinks to them in ${prefix}/include? The compiler won't
| consult those symlinks (because of the versioned headers) but the user
| can use them for reference if they wish.

If the files are there (through symlinks or whatever) the compiler
will pick them.  The solution is not put "overwrite" previous
installation.

I'll post a patch based on the existing versioning machinery.

-- Gaby


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]