egcs-980205 and m68-next-nextstep3: quick death

egcs-980205 and m68-next-nextstep3: quick death

[Toon Moene]

As the subject says:

Bootstrapping the compiler
make CC="gcc" libdir=/usr/test/lib LANGUAGES="c "
gcc  -DIN_GCC    -g   -DHAVE_CONFIG_H     -I. -I. -I./config   
-DGCC_INCLUDE_DIR=\"/usr/test/lib/gcc-lib/m68k-next-nextstep3/egcs-2.91.07/include\"  
 -DGPLUSPLUS_INCLUDE_DIR=\"/usr/test/include/g++\"   
-DOLD_GPLUSPLUS_INCLUDE_DIR=\"/usr/test/lib/g++-include\"   
-DLOCAL_INCLUDE_DIR=\"/usr/local/include\"   
-DCROSS_INCLUDE_DIR=\"/usr/test/lib/gcc-lib/m68k-next-nextstep3/egcs-2.91.07/sys-include\"  
 -DTOOL_INCLUDE_DIR=\"/usr/test/m68k-next-nextstep3/include\"  -c  
`echo ./cccp.c | sed 's,^\./,,'`
In file included from cccp.c:71:
gansidecl.h:82: macro `bcopy' used without args
gansidecl.h:92: macro `bzero' used without args
gansidecl.h:102: macro `bcmp' used without args
*** Exit 1

HTH,
Toon.

Re: egcs-980205 and m68-next-nextstep3: quick death

[Kaveh R. Ghazi]

 > From: Toon Moene <toon@moene.indiv.nluug.nl>
 > 
 > In file included from cccp.c:71:
 > gansidecl.h:82: macro `bcopy' used without args
 > gansidecl.h:92: macro `bzero' used without args
 > gansidecl.h:102: macro `bcmp' used without args
 > *** Exit 1
 > 
 > HTH,
 > Toon.

	To fix this I think it would work to do the #ifndef bcopy, etc,
as the outer conditional.  I'll write a patch tomorrow.

		--Kaveh
--
Kaveh R. Ghazi			Project Manager / Custom Development
ghazi@caip.rutgers.edu		ICon CMT Corp.

Re: egcs-980205 and m68-next-nextstep3: quick death

[Robert Lipe]

>  > In file included from cccp.c:71:
>  > gansidecl.h:82: macro `bcopy' used without args
>  > gansidecl.h:92: macro `bzero' used without args
>  > gansidecl.h:102: macro `bcmp' used without args
> 
> 	To fix this I think it would work to do the #ifndef bcopy, etc,
> as the outer conditional.  I'll write a patch tomorrow.

How about if we just migrate things to link against libiberty and
get out this form of macro madness?  Isn't that what autconf and 
libiberty are about?

Then we could lose all sorts of "private" functions in gcc such as
the "mybcopy" and "mybzero" things that pop up all over the place.

-- 
Robert Lipe       http://www.dgii.com/people/robertl       robertl@dgii.com

Re: egcs-980205 and m68-next-nextstep3: quick death

[Jeffrey A Law]

  In message < 19980207102437.57390@dgii.com >you write:
  > How about if we just migrate things to link against libiberty and
  > get out this form of macro madness?  Isn't that what autconf and 
  > libiberty are about?
  > 
  > Then we could lose all sorts of "private" functions in gcc such as
  > the "mybcopy" and "mybzero" things that pop up all over the place.
It's been in the back of my mind to link gcc against libiberty....

jeff

Re: egcs-980205 and m68-next-nextstep3: quick death

[Kaveh R. Ghazi]

 > From: Toon Moene <toon@moene.indiv.nluug.nl>
 > 
 > In file included from cccp.c:71:
 > gansidecl.h:82: macro `bcopy' used without args
 > gansidecl.h:92: macro `bzero' used without args
 > gansidecl.h:102: macro `bcmp' used without args
 > *** Exit 1
 > 
 > HTH,
 > Toon.

	Does this patch fix your problem?

		--Kaveh


Sat Feb  7 13:49:41 1998  Kaveh R. Ghazi  <ghazi@caip.rutgers.edu>

        * gansidecl.h: Check for a conflicting macro definition before
        attempting to prototype bcopy, bcmp or bzero.


*** egcs-980205/gcc/gansidecl.h~	Sat Jan 31 19:48:06 1998
--- egcs-980205/gcc/gansidecl.h	Sat Feb  7 13:40:20 1998
***************
*** 77,108 ****
  
  #endif /* ! __STDC__ */
  
! #ifdef HAVE_BCOPY
! # ifdef NEED_DECLARATION_BCOPY
  void bcopy ();
! # endif
! #else
! # ifndef bcopy
  #  define bcopy(src,dst,len) memcpy ((dst),(src),(len))
  # endif
  #endif
  
! #ifdef HAVE_BZERO
! # ifdef NEED_DECLARATION_BZERO
  void bzero ();
! # endif
! #else
! # ifndef bzero
  #  define bzero(dst,len) memset ((dst),0,(len))
  # endif
  #endif
  
! #ifdef HAVE_BCMP
! # ifdef NEED_DECLARATION_BCMP
  int bcmp ();
! # endif
! #else
! # ifndef bcmp
  #  define bcmp(left,right,len) memcmp ((left),(right),(len))
  # endif
  #endif
--- 77,108 ----
  
  #endif /* ! __STDC__ */
  
! #ifndef bcopy
! # ifdef HAVE_BCOPY
! #  ifdef NEED_DECLARATION_BCOPY
  void bcopy ();
! #  endif
! # else
  #  define bcopy(src,dst,len) memcpy ((dst),(src),(len))
  # endif
  #endif
  
! #ifndef bzero
! # ifdef HAVE_BZERO
! #  ifdef NEED_DECLARATION_BZERO
  void bzero ();
! #  endif
! # else
  #  define bzero(dst,len) memset ((dst),0,(len))
  # endif
  #endif
  
! #ifndef bcmp
! # ifdef HAVE_BCMP
! #  ifdef NEED_DECLARATION_BCMP
  int bcmp ();
! #  endif
! # else
  #  define bcmp(left,right,len) memcmp ((left),(right),(len))
  # endif
  #endif
--
Kaveh R. Ghazi			Project Manager / Custom Development
ghazi@caip.rutgers.edu		ICon CMT Corp.

Re: egcs-980205 and m68-next-nextstep3: quick death

[Jeffrey A Law]

  In message < 199802071848.NAA10522@caip.rutgers.edu >you write:

  > Sat Feb  7 13:49:41 1998  Kaveh R. Ghazi  <ghazi@caip.rutgers.edu>
  > 
  >         * gansidecl.h: Check for a conflicting macro definition before
  >         attempting to prototype bcopy, bcmp or bzero.
Looks correct to me -- I've installed it.

jeff

Re: egcs-980205 and m68-next-nextstep3: quick death

[Toon Moene]

> > From: Toon Moene <toon@moene.indiv.nluug.nl>

> > In file included from cccp.c:71:
> > gansidecl.h:82: macro `bcopy' used without args
> > gansidecl.h:92: macro `bzero' used without args
> > gansidecl.h:102: macro `bcmp' used without args
> > *** Exit 1

>  	Does this patch fix your problem?

>  		--Kaveh

[ ... patch deleted for brevity ... ]

Yes.  OTOH, I saw a discussion already about the "right" way to  
solve this (probably via libiberty ?).  Note, however, that I do  
know next to nothing about the configure business, so I'm just  
waiting for others to advise ...

Oh, BTW, does anyone have a quick answer to the question why a  
standard `./configure; make bootstrap' now leads to gcc being used  
as the initial compiler (instead of cc, assuming both are in the  
path) ?

Cheers,
Toon.

Re: egcs-980205 and m68-next-nextstep3: quick death

[Jeffrey A Law]

  In message < 9802082028.AA26597@moene.indiv.nluug.nl >you write:
  > [ ... patch deleted for brevity ... ]
  > 
  > Yes.  OTOH, I saw a discussion already about the "right" way to  
  > solve this (probably via libiberty ?).  Note, however, that I do  
  > know next to nothing about the configure business, so I'm just  
  > waiting for others to advise ...
Well, the "right" way isn't likely to be running in the immediate
future, so we might as well get things working again until the
"right" way is ready :-)


  > Oh, BTW, does anyone have a quick answer to the question why a  
  > standard `./configure; make bootstrap' now leads to gcc being used  
  > as the initial compiler (instead of cc, assuming both are in the  
  > path) ?
I thought configure always preferred gcc to cc if it could find gcc.

jeff