Re: Building shared libs as dynamically-loaded perl modules

2001-02-16 Thread Jeremy Slade
Alexandre> objects, unless the PIC objects aren't available. > > I agree here. I think convenience libraries need to compile two sets > of libraries: *.a which contains non-PIC code and *.al which contains > PIC code. And they need to be installed so they are usable by o

Re: Building shared libs as dynamically-loaded perl modules

2001-02-15 Thread Jeremy Slade
Alexandre Oliva writes: > On Feb 14, 2001, Jeremy Slade <[EMAIL PROTECTED]> wrote: > > > It seems that what I really what is to create swigShapeUtils.sl > > using the original ../../lib/*.lo files build earlier (and used to > > create libShapeUtils.sl), rather than

Re: Building shared libs as dynamically-loaded perl modules

2001-02-14 Thread Jeremy Slade
Tom Tromey writes: > >>>>> "Jeremy" == Jeremy Slade <[EMAIL PROTECTED]> writes: > > Jeremy> What I really want to build is 'swigShapeUtils.sl', which > Jeremy> corresponds to the swigShapeUtils.pm module. But automake > Jerem

Building shared libs as dynamically-loaded perl modules

2001-02-14 Thread Jeremy Slade
ibShapeUtils.la plus the .libs/libShapeUtils.a and .libs/libShapeUtils.sl, etc. So, how do I get it to build my swigShapeUtils.sl linked against the libShapeUtils.a archive lib, so there is not that run-time dependency on libShapeUtils.sl? Perhaps I'm going about this the wrong way. Please enlighten m