From: rcopg@minyos.xx.rmit.OZ.AU (Paul Gortmaker) Subject: Re: stdlib.h troubles Date: 9 Aug 1993 03:21:56 GMT
hjl@nynexst.com (H.J. Lu) writes:
>In article <SCT.93Aug5201228@ascrib.dcs.ed.ac.uk>, sct@dcs.ed.ac.uk (Stephen Tweedie) writes:
[...]
>|> I had the same problem. gcc-2.4.5 comes with it's own stdlib.h, which
>|> lives in /usr/lib/gcc-lib/i486-linux/2.4.5/include. Apparently the
>I swear that is not from me. I don't see why gcc 2.4.5 should have its
>own stdlib.h. As far as I know, Linux should not run "fixincludes" since
>there are nothing to fix in /usr/include.
...so, if Linux shouldn't run the fixincludes script, then can we toss all
the includes in " /usr/lib/gcc-lib/i486-linux/2.4.5/include" into the
garbage bin? Mind you, this makes sense, as gcc is the "cc" for Linux,
and hence the idea of having to munge the header files is silly.
>Please delete /usr/lib/gcc-lib/i486-linux/2.4.5/include/stdlib.h and
>install inc-4.4.1.tar.gz.
...my build of 2.4.5 left me with the following: float.h, limits.h, proto.h,
stdarg.h, stddef.h, syslimits.h, varargs.h, and a bunch of machine specific
varargs.h (such as va-XXXXX.h, where XXXXX = mips, alpha, sparc, ...)
laying around in /usr/lib/gcc-lib/i486-linux/2.4.5/include. Obviously the
machine specific stuff can be tossed, but what about the rest? Is the
fixincludes script broken? I don't have the sources handy anymore...
Regards,
Paul.
===========================================================================
Paul Gortmaker c/o Microelectronics and Materials Technology Centre.
Royal Melbourne Institute of Technology, GPO Box 2476V, Melbourne 3001,
Victoria, Australia. Ph (61) 3 660 2601. FAX (61) 3 662 1921.
e-mail: paul@cain.mmtc.rmit.oz.au rcopg@minyos.xx.rmit.oz.au