Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!gatech!rutgers!ucsd!ucsdhub!esosun!seismo!uunet!ficc!peter
From: peter@ficc.uu.net (Peter da Silva)
Newsgroups: comp.lang.c
Subject: Re: handling long externs with a post-processor
Keywords: was Re: "Numerical Recipes in C" is nonport
Message-ID: <1681@ficc.uu.net>
Date: 3 Oct 88 13:24:09 GMT
References: <5162@hoptoad.uucp> <225800072@uxe.cso.uiuc.edu> <4071@bsu-cs.UUCP> <4162@bsu-cs.UUCP>
Organization: SCADA
Lines: 22

In article <4162@bsu-cs.UUCP>, dhesi@bsu-cs.UUCP (Rahul Dhesi) writes:
> But we can still handle this situation.  The post-processor
> can be run once each time the system libraries are updated, to scan
> them and make a master list of all symbols in these libraries.  Then,
> each time the user's object modules are processed, the post-processor
> avoids using symbols that are already in this master list.

What about local libraries written in something other than 'C'.

You can still do it with a local format. Here's how.

Compile 'C' modules into local-format objects. These objects have long-name
externals.

Link these modules together into a global-format object. Any unsatisfied
long names at this point are an error. You may have to include the 'C'
runtime library here to allow for sprintf and strrchr.

Link these modules with your Fortran and PL/I modules.
-- 
Peter da Silva  `-_-'  Ferranti International Controls Corporation.
"Have you hugged  U  your wolf today?"            peter@ficc.uu.net