Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!att!cbnewsd!knudsen From: knudsen@cbnewsd.att.com (michael.j.knudsen) Newsgroups: comp.os.os9 Subject: Re: C Linker Library problems -- help! Keywords: OSK, C, linker, libraries Message-ID: <1991Apr30.154454.27728@cbnewsd.att.com> Date: 30 Apr 91 15:44:54 GMT References: <196@blars> <1991Apr29.223454.5112@cbnewsd.att.com> <198@blars> Organization: AT&T Bell Laboratories Lines: 77 In article <198@blars>, blarson@blars writes: > If only OSK make worked reliably. It works most of the time on simple Uh-oh. Well, now I don't feel so bad about some strange things that have happened, even on OSK 2.4 on the MM/1 68070 box. First, to avoid really long L68 command line, I merge groups of .r files into three files a.m, b.m, and c.m. My final product "depends" on those three, and each .m fiole depends on its set of .r files. Well, make only makes the first .m file in the product dependency list. The manual even warns about this (without being at all apologetic about such a shortcoming). So I have a shell script named "makem" which does "make a.m" etc., and finally links them all. You can't call these intermediate files "a.r" or else Make instantly compalins it can't find a.c to make a.r -- even tho I explicitly give the rule to make a.r right under the dependency line. What ever happened to the classic notion that explicit rules overrode the defaults? Sometimes I get strange errors from MERGE like "Can't open file blah.r" which probably means a blank or linefeed got into the file name. Worst of all, and in line with Bob Larson's comments, I put some code in one source file (out of two dozen) to fix something. No effect, but no harm either so I left that code in. Two days later, after working on some totally unrelated stuff in the same product, the fix suddenly started working! As if the first few Makes didn't "take" on that source file! Must I "touch *.c" before Make just to be sure, and bring a good SciFi novel (like the manual)? Tim (Koonce) Kientzle has a really nice PD Make for 6809 that I've used for some time, and it's been suggested to port it to OSK and just bypass Microware's job. But so far my experience with porting 6809 C code is that you get lots of voodoo errors in 68K, so not a project to be undertaken lightly. > rule gets large, the size of a rule gets large, or anything else > exceeds some apparently rediculously small internal buffer size which > has no error checking to see if the buffer overflows. Really bugs me that there's so much room in OSK, but the Make is written with small arrays and tables that overflow silently. Maybe its writers knew better than to trust their own malloc() and realloc(), or were just in a hurry? > About the only > thing that does complain about a length exceeded is command line > length, which is also way too small for complicated makefiles.... That's a relief -- at least I could try L68 on the whole s-load of .r files and skip the intermediate merges, and hear about it if it gets too long. > I'm still using damage control procedues from my experences with OSK > 2.2, so some of these bugs may be fixed later. (2.4 isn't yet > available for my machine -- I'm on the waiting list.) From my experience you have nothing to wait for (see above). I suspect all the M'ware programmers are on OS-9000, which after all runs on a REAL microprocessor (walkie-talkie company's chips don't count out there in the Real World :-( I hope someone at Microware can confirm that OSK bugs are still being fixed, tho. Pardon my flame but as a Coco 6809 survivor I can sympathize with the Kurds, and smell "abandonment" a mile away. > Instead of "make foobar" use "make foobar.r barfoo.r flowbuz.r blop.r > kerblooie.r gagchoak.r foobar". I've got a lot of little shell files Can you trust make to at least do every argument on that command line? I thought I tried and it only made the first one...mike k -- "What America needs is A Thousand Points When Lit..." knudsen@iceland.att.com