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

[Jeff Teunissen]

I wasn't confusing libraries and binaries.

I was talking about rlink because rlink is the thing that you link the
libraries into to build an executable binary, and is the thing that
supposedly barfs on RMA's output. I already know that rdump works on
merged RMA output, because I can see it working in another window on
my screen right this minute Maybe not the really old rdump source code
that comes with the compiler, but that was for version zero ROF
anyway. There may be a bug in at least some versions of rlink, or RMA,
or both, that prevent it from working in some configurations, it's not
all that unlikely.



On Tue, May 5, 2020 at 3:59 AM Walter Zambotti <zambotti at iinet.net.au> wrote:
>
> 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.
> >
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco