[Coco] Fwd: failure notice
gheskett at wdtv.com
Tue May 12 03:43:12 EDT 2015
On Tuesday 12 May 2015 02:40:36 Bill Pierce via Coco wrote:
> Gene, I haven't a clue why the email didn't go through, I used the
> same address and method I always use... probably some "Linus
> thing".... security blanket and all that... (j/k)but anyway...
Naw, likely aol has gone down the same road yahoo has with a certificate
based msg acceptance policy. That BS has rather effectively broken the
internet. And I find it a bit ironic that yahoo was first with it, when
in fact 20% of my incoming spam has been thru a yahoo server.
> The problem is that when I assemble (or compile, in the case of C
> sources) the sources to CK's clib.l, EVERY resulting ROF has 2 extra
> zeros at the end.
> Apparently, when trying to compile a C file using the merged library,
> the linker (and any other file made to use ROFs), reads the header,
> which is WAAAY different from a standard OS9 header, and get the ROF's
> size, then uses this size to calculate where the next header should
> be... So the zeros must not be figured into the size as the linker and
> CK's "lib" which separates C libraries, reports that the file is not
> an valid ROF. In fact, CK's "lib" separates the first file in the
> library then pukes on the second because it can't find the header, so
> it assumes the library is not an ROF. It will separate CK's clib.l
> fine. I have checked the assembled files against the library files
> that I've been using and they are byte-for-byte identical except for
> those two bytes at the end. Even the headers are the same.
> I tried using RMA and C.Asm, and both produce the same result. The
> resulting rofs, when merged, should make a valid lib file, but the
> linker says no, and aborts if I use the lib in a C compile.
> And I have CK's notes on the contents of the ROF header. It's much
> more complex than a standard OS9 modules header. The ROF header
> contains all the info about the file's global and dp variables as well
> as the pointers, so that the linker can tie them all together later
> when used in module. In a C library, these ROFs are left raw and just
> merged so the linker is not involved until the library is used.
> I want to make some "custom" libraries, but until I solve what's
> adding the "00 00" to the end, it ain't happenin'
Does the linker use the module length, and is this module length correct
such the the extra $0000 int is detectable, and fixable by a quick
assembly program that would copy only the valid bytes, piping that into
the merge command that makes the library?
Its a problem I never had a decade and change ago. Have you asked
Willard, who did a more recent c.prep, if he has encountered this?
If not, get the crc's of what he is using so you can tell when you've
found the ones that work.
Worse comes to worse, ded might be able to fix it by reducing the module
size by 2 bytes, do this in the raw ROF's FD sector. How difficult this
is depends on how many modules there are to fix. Keep in mind that
would probably need a v for verify to fix the files crc for the new,
shorter data length too. I think this would have to be a 2 copies of
ded running project, one to edit the FD.sector, and one to load the file
to verify that it has been fixed.
Unless you can ID the compiler module that is doing the fubar output,
thats the best idea I can come up with.
> Bill Pierce
> "Today is a good day... I woke up" - Ritchie Havens
> My Music from the Tandy/Radio Shack Color Computer 2 & 3
> Co-Contributor, Co-Editor for CocoPedia
> E-Mail: ooogalapasooo at aol.com
Cheers, Gene Heskett
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
More information about the Coco