> 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
|
