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)


Jakub Jelinek <jakub@redhat.com> writes:

| On Thu, May 16, 2002 at 11:33:14PM +0200, Gabriel Dos Reis wrote:
| > Phil Edwards <phil@jaj.com> writes:
| > 
| > | On Thu, May 16, 2002 at 11:09:59PM +0200, Gabriel Dos Reis wrote:
| > | > Phil Edwards <phil@jaj.com> writes:
| > | > | I agree wholeheartedly with the idea, but for the implementation, wouldn't
| > | > | it be easier to just make --enable-version-specific-runtime-libs the default?
| > | > 
| > | > I'm unclear as to what you mean here. 
| > | 
| > | Try just building with that flag and see where the headers go (they get
| > | installed more or less where Jakub suggests).  My suggestion is simply to
| > | have that flag be turned on by default.
| > 
| > 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.

-- Gaby


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