[Coco] C compiler self-hosting on NitrOS9 again!

[Walter Zambotti]

To whom ever said:

You keep saying "rlink is not involved", but it is. Since rlink is the
thing that does the linking of binaries, if rlink can read the ROF
files in the library (which, at least on my machine, it seems to be
able to), it can link the binary using the library.

Do not confuse binaries and libraries.

They are separate and and use different tools to create them.

Executable binaries are created with rlink.

Libraries are created with c.asm and merge.  (No linker involved).

rlink can link libraries but only if they are created with c.asm and merge.

rlink fails when it links a library created with rma and merge.

This is because rma is outputting two zero bytes at the end of the rof
which appear to be extraneous.

I'm looking at the rma code now to see why this happens! Hold tight!

Walter

On 5/5/20 10:38 am, Jeff Teunissen wrote:
> On Mon, May 4, 2020 at 7:46 PM Bill Pierce via Coco
> <coco at maltedmedia.com> wrote:
>> Jeff, rma & rlink work fine, I use them exclusively.... UNLESS you are building library files (in which rlink is not involved).
>> To build a library (like clib.l or cgfx.l), using the "clib" sources, you would think you could use c.prep, c.comp, c.opt, then rma (for "*.c" files, if it's a "*.a" file then only c.opt and rma). The resulting rofs are then merged (not linked) to form the "*.l" file to be used in c programming.
>> When rma is used, the resulting *.l file will be unusable.
> You keep saying "rlink is not involved", but it is. Since rlink is the
> thing that does the linking of binaries, if rlink can read the ROF
> files in the library (which, at least on my machine, it seems to be
> able to), it can link the binary using the library.
>
>> My C environment is:
>> rcr - custom C frontend
>> c.prep - original Tandy (any others fail on long lines and too many labels)
> I only know of one other, c_prep, and that one is not very good. cpp,
> on the other hand, I have not yet been able to break (but I haven't
> tried all that hard). It can handle source code with nice long lines
> that the old c.prep barfs on, while having the ability to deal with
> more modern preprocessor features (like "#if defined(FOO) || defined
> (BAR)", or "#if FOO == TRUE").
>
>> c.comp - ??? unknown origin ??? (I use the one from the NitrOS9 repo)
>> CNoY - custom massager only used on certain projects
>> c.opt - Original Tandy (all updated vesions suffer same problem as c.prep)
> The version of c.opt in the CoCoC repository has all of the
> optimizations the one from Tandy included, plus a couple of new ones.
> I am planning to add an option for it to do the "CnoY" thing as well
> as its ordinary optimizations, so it can be done all in one pass. It
> will probably use a "-2" argument to enable Level 2-specific
> optimizations like CnoY.
>