On Sun, Jun 3, 2012 at 1:45 AM, Jonathan Wakely wrote:
> On 3 June 2012 01:30, Jeremy Huntwork wrote:
>>
>> After reading up further, it appears that the possibility exists that the
>> script may 'fix' things in the libc headers that we don't want or need
>> 'fixed'. I'm trying to ascertain what t
On Jun 3, 2012, at 7:45 AM, Jonathan Wakely wrote:
> It's trivial to let it run and compare the fixed files to the
> originals. On my system with a recent glibc I still see lots of
> changes to limits.h, I assume they're not pointless and are worth
> having.
I believe that gcc always supplies an
On 3 June 2012 01:30, Jeremy Huntwork wrote:
>
> After reading up further, it appears that the possibility exists that the
> script may 'fix' things in the libc headers that we don't want or need
> 'fixed'. I'm trying to ascertain what things the script in particular is
> 'fixing' and which way is
> There have been discussions about the need (or lack of) for this script
> to run on the Linux From Scratch development list. In LFS gcc is
> bootstrapped in a very confined chroot environment where the only
> headers available are the Linux headers and those from glibc. What is in
> question is w
On 6/2/12 5:34 PM, Eric Botcazou wrote:
What are you after, exactly? Even on modern OSes, there might be glitches or
small incompatibilities that woud need to be fixed in order for GCC to work
properly, and fixincludes is the tried and proven tool to do that. It is
designed to modify only what
> OK, thanks for this reply. For a situation when the only available
> headers are the sanitized Linux headers and those from recent glibc
> (or some other modern libc) am I correct in assuming that this script
> is unnecessary and could, conceivably alter something that shouldn't
> be altered?
Wh
On May 28, 2012, at 7:25 PM, Jonathan Wakely wrote:
> The "upstream packages" might be a third-party OS vendor who supply
> their own compiler and have no interest in supporting GCC. Even if the
> OS system headers get changed, that doesn't help users who have the
> unchanged version (e.g. someon
On 29 May 2012 00:19, Jeremy Huntwork wrote:
> Hello,
>
> I'm endeavoring to understand the history and purpose of the fixincludes
> script. The README-fixinc states that the purpose is to fix
> ANSI-incompatible headers which 'many vendors supply'. Is this really still
> the case? Certainly by now
Basile STARYNKEVITCH writes:
> Why is it still useful on recent GNU/Linux systems?
In general, it's not. But future versions of gcc may want changes to
current versions of glibc. We've seen that happen in the past, and it
is likely to happen again in the future. (E.g., we needed to use
fixinc
Richard Guenther wrote:
On Sat, Jan 23, 2010 at 5:43 PM, Franz Fehringer wrote:
but an OS update could lead to updated C runtime headers?
Yes.
There is still one point I don't understand about fixincludes.
Why is it still useful on recent GNU/Linux systems?
From what I understood, fixi
On Sat, Jan 23, 2010 at 5:43 PM, Franz Fehringer wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> understood.
> but an OS update could lead to updated C runtime headers?
Yes.
Richard.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
understood.
but an OS update could lead to updated C runtime headers?
Am 23.01.2010 17:39, schrieb Richard Guenther:
> On Sat, Jan 23, 2010 at 5:34 PM, Franz Fehringer wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Hi all,
>>
>> I
On Sat, Jan 23, 2010 at 5:34 PM, Franz Fehringer wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi all,
>
> I have two hopefully not too dull questions about the gcc fixincludes
> mechanism:
> 1) When after the initial fixinclude run (parts of) new software is
> installed into /usr/i
On Wed, May 20, 2009 at 2:47 PM, Steve Ellcey wrote:
> I have a question about the use of sed by fixincl and mkheaders
> and a change that was made between 4.3.* and 4.4.0.
> After this patch, the sed used when building GCC is saved in a config
> file and that path to sed is used when you run mkh
>> Was it fixincludes or was it the mkheaders script ?
>>
>> and why ?
>
> Because system headers should not define something in the users namespace,
> certainly not a non-uglified three-letter name such as "sun".
>
> Consider
>
> #include
>
> int sun;
>
> which will not build otherwise.
I did
On Sat, Feb 7, 2009 at 7:27 PM, Dennis Clarke wrote:
>
> This is just a question. Hopefully someone can shed some light on what the
> fixincludes stage of "make install" does. I am making the assumption that
> the "make install" stage is where these headers get mangled or modified.
>
> This is on
Andreas Jaeger wrote:
Running make check in fixincludes on x86_64-gnu-linux I get the
following failure:
Just grepping for "_STRING_INCLUDED" it is easy to see the input rule in
inclhack.def that defines this transformation, and the output rule in
fixincl.x that actually does the transformati
17 matches
Mail list logo
