Re: Shared library support


To Manu Rouat <emmanuel.rouat@wanadoo.fr>
From Arno <A.W.Peters@ieee.org>
Date Tue, 7 Dec 1999 09:32:05 +0100
Cc ng-spice <ng-spice-devel@ieee.ing.uniroma1.it>
Delivered-To mailing list ng-spice-devel@ieee.ing.uniroma1.it
In-Reply-To <384C90CB.786B3975@wanadoo.fr>; from emmanuel.rouat@wanadoo.fr on Mon, Dec 06, 1999 at 11:44:59PM -0500
Mailing-List contact ng-spice-devel-help@ieee.ing.uniroma1.it; run by ezmlm
References <19991203222742.A5038@cgmd95104.chello.nl> <384C90CB.786B3975@wanadoo.fr>
Reply-To ng-spice-devel@ieee.ing.uniroma1.it
User-Agent Mutt/1.0i

On Mon, Dec 06, 1999 at 11:44:59PM -0500, Manu Rouat wrote:
> Arno wrote:
> > 
> > Hi Manu,
> > 
> > Enclosed you'll find a preliminary patch to add shared library support
> > to ng-spice.  I get it to compile everything as shared lib but when I
> > try to link it to the spice main program, all the symbols in the libs
> > doesn't seem to be found: there are a lot of undefined references.
> 
> OK, I've had a good look at this - there are several problems, but
> the biggest one seems to be the following: it seems that the devices
> that we would like to compile as shared libraries actually call
> functions that are defined in an other library (for instance
> libparser.a) that will be linked to the main program later
> (statically linked, that is, not dynamicaly). [...]

I made all libraries dynamic.  From your diagnosis, I think I know the
solution: declare the additional shared libraries on compile-time so
that the symbols get resolved before we try to link the resulting
model library with ng-spice.  I'll try to make that work this evening.
Once the shared libraries work, we can look at producing a registering
function to load models on demand.

> [...] Basicaly, what we want to do is to have a monolithic simulator
> (ngspice) which is capable of loading a shared library (for example
> libbsim3.so) when necessary.  If this library actually does calls to
> functions that are in the simulator, I don't know how to do
> it. [...]

Me neither, but we can learn from our experiences with dynamically
loaded core functionality.  In this case, ld does all the work for
us.  In the case above, we have to do some of the work ourselves.

> [...] I
> guess that it is possible, since linux modules work that way, but it
> seems to me that spice wasn't intended to be used that way, and the
> code makes it probably hard to achieve it. Also , there are probably
> dependencies between models as well (for instance all models use
> capacitances).

For testing the model code, I am looking at extracting the model
interface and support functions to link it with a standalone program.
It could than do automatic validation of a model, based on (for
example) empiric results.  If that functions properly, the
modifications will also help us with the dynamically loaded models.

> I will see if I can make it work with one model (bsim3 for instance). All
> other libraries should be built as before.

I will try my hand at it as well.

-- 
Arno

Partial thread listing: