Xref: utzoo news.software.b:7169 gnu.gcc.help:564
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!spool.mu.edu!cs.umn.edu!dmshq!com50!pwcs!hawkmoon!det
From: det@hawkmoon.MN.ORG (Derek E. Terveer)
Newsgroups: news.software.b,gnu.gcc.help
Subject: /bin/cc vs. gcc with Cnews on Esix 5.3.2-D
Keywords: size_t
Message-ID: <1991Mar22.233036.9739@hawkmoon.MN.ORG>
Date: 22 Mar 91 23:30:36 GMT
Organization: Home System (One of the Eternal Champions); Eagan, MN, 55123-2507, USA
Lines: 36

I have just applied some recent patches for Cnews (up to 15-Dec-1990) and
rebuilt the software.  I am using gcc 1.39.  In the file hdrdefs.c i got the
following errors:

/usr/local/lib/gcc/gcc-include/stddef.h:35: conflicting types for `size_t'
/usr/include/sys/types.h:35: previous declaration of `size_t'

The appropriate lines are:

/usr/local/lib/gcc/gcc-include/stddef.h:35:
typedef unsigned long size_t;

/usr/include/sys/types.h:35:
typedef	unsigned int	size_t;		/* len param for string funcs */

Obviously, there is a conflict.  Esix defines size_t as an int and GNU defines
it as a long.  I would like to use gcc for the entire compile, if possible, and
would like to know if it would break anything in general if I either change the
Esix types.h definition of size_t to match the GNU one or simply comment it
out?  I believe that i would have to keep it as an int if i were to be
compiling system software, but what about stand-alone packages?  Would there be
a conflict with already compiled libraries?  (Probably so?)

This conflict will undoubtedly arise in other instances, so has anyone else run
into this problem and what did you do?

Please e-mail to	det@hawkmoon.mn.org
unless you think this is of general interest.

Thanks,

derek
-- 
Derek "Tigger" Terveer	det@hawkmoon.MN.ORG -- U of MN Women's Lax
I am the way and the truth and the light, I know all the answers; don't need
your advice.  -- "I am the way and the truth and the light" -- The Legendary Pink Dots