🚀 go-pugleaf

 
 > tkacik@rphroy.UUCP (Tom Tkacik) writes ...
 
 >When linking a Modula-2 program, the entire library is included,
 >even routines that are not needed.  If any of those unused routines call
 >a routine from another library, that entire library is also included.
 >The result is a short program burdened by a lot of unused library code.
 >(I know this is an implementation problem, not a Modula-2 problem.)
 
 >I have the source code for those libraries, and would like to re-create
 >them so that each routine is in its own .o file, and use the archiver
 >to collect them into a single library.
 
TopSpeed's "smart linker" solves this by recognizing that the unit of
linking ought to be the object (i.e. procedure/variable), rather than
the whole module.  (I haven't seen their Modula 2 yet, but the TopSpeed
C does this, and a direct result is that their library sources are in a
couple of big source files, rather than the hundreds of small ones we
have become accustomed to.  But the executable code stays small.)
 
 >What I was thinking of doing is to remove all but a single procedure from
 >a source library file (perhaps using the C preprocessor and its
 >#ifdef directive) and compile the file.
 >Then do this for each procedure in the file.  All of the compiled
 >files would be given different names, (the linker does not
 >care what the file is called), and collected into a single library.
 
 >This seems all well and good, execpt for global variables.
 >If a global variable is used by two procedures, it would have to remain in
 >the source file twice, and be compiled twice.  The result would be a
 >multipy defined variable.  But if I left it out during one of the compiles,
 >the compiler would complain.  I can't IMPORT it from another file, because
 >then the compiler would give it the wrong name.
 
I cannot see any mechanisms in Modula that would allow you to
transparently 'break' one module into N fragments, while still
allowing the user to believe that they are all part of the same module.
 
I think you're trying to solve the problem at the wrong level.  It is
the linker that needs improvement.  The Modula libraries are organized into
LOGICALLY coherent modules.  The fact that the linker tries to treat
these as PHYSICALLY coherent units is a mess.
 
Rather devote your efforts to providing a smart linker.  A quick and
dirty approach may require nothing more than a script file or two.
 
For example, you could link with the usual mechanisms and produce a map
file or a list of all the routines you actually need.  Then use the
standard library maintenance utilities to extract from the real
libraries only the bits you want for that application, and re-build
them into a special purpose lean-'n-mean library.  Then just re-link
with the new improved library.  (I'm not sure all library managers would
be able to extract pieces of a module, but it is worth a try.)
 
Of course, are not worried about the code size during development
(are you?), so you'd only need to do this once when your product
is ready for release.  This way the slowwww linking wouldn't be so bad!
 
Pete

--
EP Wentworth - Dept. of Computer Science - Rhodes University - Grahamstown.
Internet: cspw.quagga@f4.n494.z5.fidonet.org
Uninet: cspw@quagga
uucp: ..uunet!m2xenix!quagga!cspw



--  
uucp: uunet!m2xenix!puddle!5!494!4.0!cspw.quagga
Internet: cspw.quagga@p0.f4.n494.z5.fidonet.org