Re: [Cobolforgcc-devel] Building Old Source - Questions

[<te...@me...>]

> Tim, I've run into a stumbling block that I think I can fix but the
> question is what is the best way to do it.
> 
> The problem is when the build process gets into the gcc/cobol
> directory and starts compiling some cob_* programs and we soon run
> into missing dependencies.
> 
> One situation as an example:
> 
> + one or more files include gcc/system.h which has a macro that
> redefines abort() as fancy_abort() which is NOT in any internal
> library but is defined in gcc/gcc.o
> 
> + solutions I can think of:
> 
>  - start a gcc/libfrontend.a library to capture such functions for use
> by cobol and other front ends (that would require some
> approval/coordination with gcc)
> 
>  - add a macro in gcc/system.h to undef the abort macro for COBOL
> (that would also require coop of gcc)
> 
>  - start a cobol run time library and include the function (overkill?)
> 
>  - start a cobol build time library and include necessary function
dependencies
> 
>  - make a copy of gcc/system.h as gcc/cobol/system.h and modify it as
> necessary for the abort case (but there may be other dependencies)
> 
> I don't know which, if any, solution is best.   What I'm going to try
> first is modifying gcc/system.h to undef the abort macro and see how
> far I get.
> 
> In the words of Bill O'Reilly, "What say you?"
> 
> -Tom
> 
> Tom Browder
> Niceville, Florida;;

Which module is it trying to compile / link? If it's the main compiler cob1
then there must be an object file that contains fancy_abort. That would
need to be added to the list for linking.

If it's the preprocessor then something needs to be done to make it not try
and call fancy_abort. For example, add #undef abort.

I had similar problems with malloc, which they kindly redefined. Many other
similarly evil things go on in gcc.

Tim
Josling

Message sent using MelbPC WebMail Server