Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!blars!blarson From: blarson@blars Newsgroups: comp.os.os9 Subject: Re: C Linker Library problems -- help! Keywords: OSK, C, linker, libraries Message-ID: <198@blars> Date: 30 Apr 91 04:30:07 GMT References: <196@blars> <1991Apr29.223454.5112@cbnewsd.att.com> <18814@sdcc6.ucsd.edu> Sender: news@usc Reply-To: blarson@usc.edu Lines: 36 Nntp-Posting-Host: dianne.usc.edu Originator: blarson@dianne.usc.edu In article <18814@sdcc6.ucsd.edu> jclark@sdcc6.ucsd.edu (John Clark) writes: >May be it's better for the >'programmer' to simplify the situation by coding one function per >source file. That has been my policy(where ever possible) for some >time. The main problem is the number of modules. But with 'make' and >appropriate makefiles the problem is managable. If only OSK make worked reliably. It works most of the time on simple makefiles and fails strangly when the number of routines linked gets large, the number of rules get large, the number of dependencies of a rule gets large, the size of a rule gets large, or anything else exceeds some apperently rediculously small internal buffer size which has no error checking to see if the buffer overflows. About the only thing that does complain about a length exceeded is command line length, which is also way to small for complicated makefiles.... (The usual symptom is to just start ignoring rules, changing dependencies, and things like that rather than direct error messages.) 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.) The "usual workaround" is to request each file on the make request rather than depending on the rules to find out the module is needed. 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 named "maker" in various directories with commands like this. -- blarson@usc.edu C news and rn for os9/68k! -- Bob Larson (blars) blarson@usc.edu usc!blarson Hiding differences does not make them go away. Accepting differences makes them unimportant.