Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!batcomputer!riley
From: riley@batcomputer.tn.cornell.edu (Daniel S. Riley)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Lattice libraries
Message-ID: <7872@batcomputer.tn.cornell.edu>
Date: 2 May 89 19:02:36 GMT
References: <108@snll-arpagw.UUCP> <2802@cps3xx.UUCP>
Reply-To: riley@tcgould.tn.cornell.edu (Daniel S. Riley)
Organization: Cornell Theory Center, Cornell University, Ithaca NY
Lines: 21

In article <2802@cps3xx.UUCP> porkka@frith.UUCP (Joseph A Porkka) writes:
>In article <108@snll-arpagw.UUCP> paolucci@snll-arpagw.UUCP (Sam Paolucci) writes:
>->Obviously this is not the right answer.  This makes it impossible to
>->generate large libraries (like GKS) with Lattice.  I guess I'll have
>->to do it with Manx.  I know that their librarian does not crap out.
>Aren't libraries just JOIN'ed #?.o files?

Originally, they were just joined .o files, but that requires that the linker
read through most of the library during scanning, which is slow.  So Lattice
added an index hunk at the end of the library, which oml maintains.  blink
will still accept the old style libraries, but joining two new style
libraries will not work, and one old style library that big would be mucho
slow.  It might be possible to write a little program to merge two libraries
without going through oml, but that sort of tomfoolery shouldn't be
necessary.

If this really is a built in limitation to oml and not an out-of-memory
problem, Lattice needs to get their act together and fix it.

-Dan Riley (riley@tcgould.tn.cornell.edu, cornell!batcomputer!riley)
-Wilson Lab, Cornell U.