This is the mail archive of the
libc-hacker@sourceware.cygnus.com
mailing list for the glibc project.
Re: Problems installing glibc in /usr/local
- To: Roland McGrath <roland@frob.com>
- Subject: Re: Problems installing glibc in /usr/local
- From: Zack Weinberg <zack@rabi.phys.columbia.edu>
- Date: Wed, 09 Sep 1998 12:54:47 -0400
- cc: Andreas Jaeger <jaeger@informatik.uni-kl.de>, libc-hacker@cygnus.com
On Wed, 9 Sep 1998 11:55:05 -0400, Roland McGrath wrote:
>> I think we should override gcc's <limits.h> entirely.
>
>Those definitions should not be in maintained two separate places in two GNU
>packages.
Of course not. I'm advocating that we take over that header.
>> This would be easy -
>> just take out the #include_next and the #ifndef around the ANSI limits
>> definitions. We'd have to specialize those limits to each processor, but
>> that should only require a bits/ansi_lim.h for wordsize-32 and wordsize-64.
>> gcc's header already defers to the one we install.
>
>That misstates the intent of the existing code. gcc's header uses
>#include_next in the way it does (with various #ifdef's) precisely so that
>glibc's header and gcc's header will cooperate as they do now to have gcc
[...]
I should have been clearer. I know what the intent of the existing
code is. I was trying to say that taking over limits.h requires no
changes on the gcc side. The existing gcc header will cooperate with
a libc header that wants to do everything itself; this may not have
been the intent of the code but it'll work anyway.
zw