fixincludes problem

fixincludes problem

[Andrew Crabtree]

Could somebody tell me how to disable fixincludes from running
in certain situations. Here's the scenarion where I have problems

typhoon:andrewc$ uname -a
HP-UX typhoon A.09.05 A 9000/715 2005943745 two-user license

configure --target=i586-go32-msdos

Egcs used to "fix" the include files from /usr/include for the
cross compiler to use.  It now properly looks in /usr/local/i586-go32-msdos
for include files, but when it fixes them they are no longer usable.
I'd just like to disable fixincludes from running whenever cross-comiling
to the msdos target, as the includes are ok as is.  

I'm not on the list so please cc replies

Thanks in advance

Andy



--
_______       ___________________________________________________________
           /                       	                  Andrew Crabtree 
          /                          	      Workgroup Networks Division 
         ____       ___  /                                Hewlett-Packard 
        /     /    /    /   		                    Roseville, CA 
     __/   __/    _____/                                     916/785-1675
                 /                           andrewc@rosemail.rose.hp.com
___________   __/   _____________________________________________________

Re: fixincludes problem

[Jeffrey A Law]

  In message < 199801100040.AA025882840@typhoon.rose.hp.com >you write:
  > Could somebody tell me how to disable fixincludes from running
  > in certain situations. Here's the scenarion where I have problems
Set FIXINCLUDES to "Makefile.in" in the Makefile.

However, I don't recommend it -- we should instaed figure out why your
include files are trashed and fix that problem instead.

fixincludes is vital to the proper operation of gcc.

jeff

Re: fixincludes problem

[Andrew Crabtree]

>   > Could somebody tell me how to disable fixincludes from running
>   > in certain situations. Here's the scenarion where I have problems
> Set FIXINCLUDES to "Makefile.in" in the Makefile.
Thank you.  I ran across this for other configurations but 
wasn't sure if it was what I should do or not.
 
> However, I don't recommend it -- we should instaed figure out why your
> include files are trashed and fix that problem instead.
> fixincludes is vital to the proper operation of gcc.
I am very unknowledgable about the whole configure/build process, 
so these next questions are more from ignorance than anything.  

There is no 'native' compiler, header files, whatever else for 
a DJGPP target. the include files are all provided in a separate
download package when you install things.  Why would we ever 
want to fixincludes for this particular target?  The old 2.7.2 
way didn't even use the standard configure method.  Its only an
option now since bash has been ported to dos.

And, why run fixincludes when we are generating a cross-compiler?
I guess perhaps changes to gcc would make re-fixing files necessary.
OK - I'll buy that.   

I will go back to try to get specifics on
what changes to the header files are breaking things and reports
them.

Andy

--
_______       ___________________________________________________________
           /                       	                  Andrew Crabtree 
          /                          	      Workgroup Networks Division 
         ____       ___  /                                Hewlett-Packard 
        /     /    /    /   		                    Roseville, CA 
     __/   __/    _____/                                     916/785-1675
                 /                           andrewc@rosemail.rose.hp.com
___________   __/   _____________________________________________________

Re: fixincludes problem

[Jeffrey A Law]

  In message < 199801110722.AA159173374@typhoon.rose.hp.com >you write:
  > 
  > >   > Could somebody tell me how to disable fixincludes from running
  > >   > in certain situations. Here's the scenarion where I have problems
  > > Set FIXINCLUDES to "Makefile.in" in the Makefile.
  > Thank you.  I ran across this for other configurations but 
  > wasn't sure if it was what I should do or not.
Which ones?  There should be _very_ few which do this.

  > I am very unknowledgable about the whole configure/build process, 
  > so these next questions are more from ignorance than anything.  
  > 
  > There is no 'native' compiler, header files, whatever else for 
  > a DJGPP target. the include files are all provided in a separate
  > download package when you install things.  Why would we ever 
  > want to fixincludes for this particular target?  The old 2.7.2 
  > way didn't even use the standard configure method.  Its only an
  > option now since bash has been ported to dos.
  > 
  > And, why run fixincludes when we are generating a cross-compiler?
  > I guess perhaps changes to gcc would make re-fixing files necessary.
  > OK - I'll buy that.   
  > 
  > I will go back to try to get specifics on
  > what changes to the header files are breaking things and reports
  > them.
Most include files have subtle bugs in them, regardless of where they
originate from.  It has nothing to do with native vs cross -- whatever
include files you're using need to be scanned and problems fixed.


An interesting exercise might be to run fixincludes and see exactly what
it changes for the include files for djgpp.  


jeff

Re: fixincludes problem

[Andrew Crabtree]

>   > > Set FIXINCLUDES to "Makefile.in" in the Makefile.
>   > Thank you.  I ran across this for other configurations but 
>   > wasn't sure if it was what I should do or not.
> Which ones?  There should be _very_ few which do this.

alpha*-*-linux-gnuecoff*)
alpha*-*-linux-gnulibc1*)
alpha*-*-linux-gnu*)
alpha*-dec-vms*)
arm-semi-aout | armel-semi-aout)
arm-semi-aof | armel-semi-aof)
arm-*-linux-gnuaout*)
c1-convex-*)
c2-convex-*)
c32-convex-*)
c34-convex-*)
 c38-convex-*)
hppa1.1-*-osf*)
hppa1.0-*-osf*)
hppa1.1-*-bsd*)
hppa1.0-*-bsd*)
 hppa*-*-lites*)
i[3456]86-*-linux-gnuoldld*)
i[3456]86-*-linux-gnuaout*)
i[3456]86-*-linux-gnulibc1)
i[3456]86-*-linux-gnu*)
i[3456]86-moss-msdos* | i[3456]86-*-moss*)
i[3456]86-*-pe | i[3456]86-*-cygwin32)
i[3456]86-*-mingw32)

OK - I'm getting tired of copying and pasting. :)  None of these
seem too mainstream though...

> Most include files have subtle bugs in them, regardless of where they
> originate from.  It has nothing to do with native vs cross -- whatever
> include files you're using need to be scanned and problems fixed.
OK - But for DJGPP the header files are designed to work only
with GCC.  There is no native system that they were coded for.
Since cygwin disables fixincludes is it reasonable to 
do for DJGPP also?
 
> An interesting exercise might be to run fixincludes and see exactly what
> it changes for the include files for djgpp.  
Well, this is how i found it it was a problem originally of course. 
Stdio and stddef had fatal errors in both for starters.   I 
am in the middle of bootstrapping so scrapped the bad headers but
will repeat when I'm done.

Andy


--
_______       ___________________________________________________________
           /                       	                  Andrew Crabtree 
          /                          	      Workgroup Networks Division 
         ____       ___  /                                Hewlett-Packard 
        /     /    /    /   		                    Roseville, CA 
     __/   __/    _____/                                     916/785-1675
                 /                           andrewc@rosemail.rose.hp.com
___________   __/   _____________________________________________________

Re: fixincludes problem

[Jeffrey A Law]

  In message < 199801122057.AA074218662@typhoon.rose.hp.com >you write:
  > 
  > >   > > Set FIXINCLUDES to "Makefile.in" in the Makefile.
  > >   > Thank you.  I ran across this for other configurations but 
  > >   > wasn't sure if it was what I should do or not.
  > > Which ones?  There should be _very_ few which do this.
  > 
  > alpha*-*-linux-gnuecoff*)
  > alpha*-*-linux-gnulibc1*)
  > alpha*-*-linux-gnu*)
  > alpha*-dec-vms*)
  > arm-semi-aout | armel-semi-aout)
  > arm-semi-aof | armel-semi-aof)
  > arm-*-linux-gnuaout*)
  > c1-convex-*)
  > c2-convex-*)
  > c32-convex-*)
  > c34-convex-*)
  >  c38-convex-*)
  > hppa1.1-*-osf*)
  > hppa1.0-*-osf*)
  > hppa1.1-*-bsd*)
  > hppa1.0-*-bsd*)
  >  hppa*-*-lites*)
  > i[3456]86-*-linux-gnuoldld*)
  > i[3456]86-*-linux-gnuaout*)
  > i[3456]86-*-linux-gnulibc1)
  > i[3456]86-*-linux-gnu*)
  > i[3456]86-moss-msdos* | i[3456]86-*-moss*)
  > i[3456]86-*-pe | i[3456]86-*-cygwin32)
  > i[3456]86-*-mingw32)
Hmmm, the linux configs in particular are wrong (math.h defines struct exception)
as are most of the bsd/lites configs.

  > OK - But for DJGPP the header files are designed to work only
  > with GCC.  There is no native system that they were coded for.
  > Since cygwin disables fixincludes is it reasonable to 
  > do for DJGPP also?
I understand that -- that doesn't change the fact that the include
files provided are often broken -- yes, even when they're designed to
work with GCC.  This generally happens due to changes in gcc itself
that require parts of include files to be fixed.

The most notorious one of late is struct exception in math.h which causes
severe grief to the C++ compiler because exception is a reserved word.

jeff

Re: fixincludes problem

[Andrew Crabtree]

> I understand that -- that doesn't change the fact that the include
> files provided are often broken -- yes, even when they're designed to
> work with GCC.  This generally happens due to changes in gcc itself
> that require parts of include files to be fixed.
> 
> The most notorious one of late is struct exception in math.h which causes
> severe grief to the C++ compiler because exception is a reserved word.

OK - DJGPP definitely has the exception problem.  The 'fixed' version
is pretty ugly though.  It repeats stuff.

The big problem appears to be what fixincludes does to stddef.h.  The original
is below (this is the whole file, its short)

The 'fixed' version appears to be an entirely new file, and has 
references to all sorts of other machine architectures.  The top portion
is below the original.

Besides the struct exception is there any other common problems between
2.7.2 and 2.8?

Thanks

Andrew



fixed math.h

#ifdef __cplusplus
#define exception __math_exception
#endif
#ifdef __cplusplus
#define exception __math_exception
#endif
struct exception {
#ifdef __cplusplus
#undef exception
#endif
#ifdef __cplusplus
#undef exception
#endif
	int type;
	char *name;
	double arg1;
	double arg2;
	double retval;
};


original stddef.h

/* Copyright (C) 1994 DJ Delorie, see COPYING.DJ for details */
#ifndef __dj_include_stddef_h_
#define __dj_include_stddef_h_

#ifdef __cplusplus
extern "C" {
#endif

#include <sys/djtypes.h>
  
#define NULL 0
#define offsetof(s_type, mbr) ((size_t) &((s_type *)0)->mbr)
typedef int ptrdiff_t;

__DJ_size_t
#undef __DJ_size_t
#define __DJ_size_t
__DJ_wchar_t
#undef __DJ_wchar_t
#define __DJ_wchar_t

#ifndef __dj_ENFORCE_ANSI_FREESTANDING

#ifndef __STRICT_ANSI__

#ifndef _POSIX_SOURCE

#endif /* !_POSIX_SOURCE */
#endif /* !__STRICT_ANSI__ */
#endif /* !__dj_ENFORCE_ANSI_FREESTANDING */

#ifndef __dj_ENFORCE_FUNCTION_CALLS
#endif /* !__dj_ENFORCE_FUNCTION_CALLS */

#ifdef __cplusplus
}
#endif

#endif /* !__dj_include_stddef_h_ */



fixed stddef.h


#if (!defined(_STDDEF_H) && !defined(_STDDEF_H_) && !defined(_ANSI_STDDEF_H) \
     && !defined(__STDDEF_H__)) \
    || defined(__need_wchar_t) || defined(__need_size_t) \
    || defined(__need_ptrdiff_t) || defined(__need_NULL) \
    || defined(__need_wint_t)

/* Any one of these symbols __need_* means that GNU libc
   wants us just to define one data type.  So don't define
   the symbols that indicate this file's entire job has been done.  */
#if (!defined(__need_wchar_t) && !defined(__need_size_t)	\
     && !defined(__need_ptrdiff_t) && !defined(__need_NULL)	\
     && !defined(__need_wint_t))
#define _STDDEF_H
#define _STDDEF_H_
/* snaroff@next.com says the NeXT needs this.  */
#define _ANSI_STDDEF_H
/* Irix 5.1 needs this.  */
#define __STDDEF_H__
#endif

#ifndef __sys_stdtypes_h
/* This avoids lossage on SunOS but only if stdtypes.h comes first.
   There's no way to win with the other order!  Sun lossage.  */

/* On 4.3bsd-net2, make sure ansi.h is included, so we have
   one less case to deal with in the following.  */
#if defined (__BSD_NET2__) || defined (____386BSD____) || defined (__FreeBSD__) || defined(__NetBSD__)
#include <machine/ansi.h>
#endif

/* In 4.3bsd-net2, machine/ansi.h defines these symbols, which are
   defined if the corresponding type is *not* defined.
   FreeBSD-2.1 defines _MACHINE_ANSI_H_ instead of _ANSI_H_ */
#if defined(_ANSI_H_) || defined(_MACHINE_ANSI_H_)
#if !defined(_SIZE_T_) && !defined(_BSD_SIZE_T_)
#define _SIZE_T
#endif
#if !defined(_PTRDIFF_T_) && !defined(_BSD_PTRDIFF_T_)
#define _PTRDIFF_T
#endif
/* On BSD/386 1.1, at least, machine/ansi.h defines _BSD_WCHAR_T_
   instead of _WCHAR_T_. */
#if !defined(_WCHAR_T_) && !defined(_BSD_WCHAR_T_)
#ifndef _BSD_WCHAR_T_
#define _WCHAR_T
#endif
#endif

Re: fixincludes problem

[Jeffrey A Law]

  In message < 199801140008.AA114026512@typhoon.rose.hp.com >you write:
  > > The most notorious one of late is struct exception in math.h which causes
  > > severe grief to the C++ compiler because exception is a reserved word.
  > 
  > OK - DJGPP definitely has the exception problem.  The 'fixed' version
  > is pretty ugly though.  It repeats stuff.
Weird.  I wonder if the djgpp version already had one of the #ifdef/#endif
pairs -- else something in fixincludes or sed has gone nuts.

  > The big problem appears to be what fixincludes does to stddef.h.  The
  > original is below (this is the whole file, its short)
This isn't done by fixincludes -- gcc uses its own stddef.h which bears
no resemblance to any one provided by the system (this is true for a few
files, including stddef.h, varargs.h, stdarg.h and a few others).

  > Besides the struct exception is there any other common problems between
  > 2.7.2 and 2.8?
That's the only one that immediately comes to mind...  
jeff

Re: fixincludes problem

[Andrew Crabtree]

> The 'fixed' version
>   > is pretty ugly though.  It repeats stuff.
> Weird.  I wonder if the djgpp version already had one of the #ifdef/#endif
> pairs -- else something in fixincludes or sed has gone nuts.
This seems likely.  The original header file I put in /usr/local/lib/gcc....
did not have any #if __cplus_plus around the struct expection.  But
I do build snapshots fairly regularly so its likely that math.h had 
already been fixed during a previous install.  At least, the version
currently in /usr has one set of #ifdefs around it.  

> This isn't done by fixincludes -- gcc uses its own stddef.h which bears
> no resemblance to any one provided by the system (this is true for a few
> files, including stddef.h, varargs.h, stdarg.h and a few others).
Oh - well this is my problem then.  After building libgcc
the make process crashes with

__gcc_bcmp
_varargs
__dummy
_eprintf
In file included from ./libgcc2.c:1393:
include/stdio.h:36: redefinition of `size_t'
include/stddef.h:168: `size_t' previously declared here

I just assumed it was the fixinclude's screwing things up.  Does gcc
intend that its newly supplied copy of stddef.h be used always 
by the resulting cross-compiler?  DJs stddef.h is very specific to it, 
and cannot be replaced by a generic one.  Will setting fixincludes=Makefile.in
disable this version of stddef.h from being used?  Or alternatively, can
I just modify the copy of stddef that will be used to support the DJ 
specific stuff?  Right now, I just copy the original DJ supplied stddef.h
into the build directory and restart things.

Thanks for the help

Andy

--
_______       ___________________________________________________________
           /                       	                  Andrew Crabtree 
          /                          	      Workgroup Networks Division 
         ____       ___  /                                Hewlett-Packard 
        /     /    /    /   		                    Roseville, CA 
     __/   __/    _____/                                     916/785-1675
                 /                           andrewc@rosemail.rose.hp.com
___________   __/   _____________________________________________________

Re: fixincludes problem

[Jeffrey A Law]

  In message < 199801141810.AA034401445@typhoon.rose.hp.com >you write:
  > by the resulting cross-compiler?  DJs stddef.h is very specific to it, 
  > and cannot be replaced by a generic one.  Will setting fixincludes=Makefile  > .in
  > disable this version of stddef.h from being used?
Nope.  stddef.h and friends are installed by other mechanisms.  I
don't remember them off the top of my head.

You might look at the definition of USER_H for linux, netbsd and other
similar systems that try to avoid sucking in too many of gcc's header
files.

jeff