broken after libtoolswitch on

Sat Feb 19 13:32:00 GMT 2000


On Fri, 18 Feb 2000, Brian Gough wrote:

> The multilib example is interesting, and works for me. I tried to do
> the same [ ... ]
> with SUBLIBS = blas/libgslblas.a blas/libgslblasnative.a ... but I got
> the same error,
> make[2]: Entering directory `/home/bjg/gsl'
> /bin/sh ./libtool --mode=link gcc  -g -O2  -o -rpath /usr/local/lib  version.lo blas/ blas/ block/ dht/ eigen/ err/ err/ fft/ histogram/ ieee-utils/ integration/ interpolation/ linalg/ matrix/ min/ monte/ multimin/ multiroots/ ode-initval/ poly/ randist/ rng/ roots/ siman/ specfunc/ statistics/ sum/ sys/ utils/ vector/ -lm 
> libtool: link: error: cannot link shared libraries into libtool libraries
> make[2]: *** [] Error 1
> whenever I used pkglib_LTLIBRARIES for in the subdirectory
>'s. It would only link if they were noinst_LTLIBRARIES.
> Maybe I am doing something wrong.

No, you did right.  Dave Morrison was cheating!  ;-)

I came across the same problem you did.  Then I downloaded Dave's
multilib, which seemed to be equivalent to what I was doing.  The's were the same, anyway --- pkglibs in subdirs, linked
together into a top-level library.  But Dave's multilib worked! 

The difference came down to this: I was using libtool version 1.3.3, and
Dave was using a CVS snapshot of libtool.  I checked the latest "released" 
libtool version (1.3.4) but it is still broken.  So this fix in libtool is
fairly recent. 


It appears that if one indeed wants to install a slew of pkglibs *and* a
conglomerate libgsl, you have to move to CVS libtool. 

Personally, I can't fathom a reason for installing *both* the individual
and conglomerate libraries.  Is it the library size?

At any rate, if one is satisfied with ONLY the conglomerate, then packing
a bunch of noinst_LTLIBRARIES in the subdirectories into the libgsl *is*
supported in released libtool versions.


More information about the Gsl-discuss mailing list