libvariants / Re: Need more

[Guido Draheim]

Actually, I'm quite with Ralph.

(a) I'm currently resolving the .a module problem with using
    rpm packages and friends to which I say they shall use only
    the dynamic modules - so the static ones don't get shipped.

    I don't mind that libtool creates the static-objects but
    I do mind that they get installed along. They are unneeded 
    for the least - the lib users don't ever use them. They
    are bloat, making a system fat and filled with rubbish.

(b) I'm having a problem with the default-libname install due
    to the multibuilds I'm going through, in some other places
    already recorded as a problem for 32-vs-64 bit variants.
    I'm handling it by having two builddirs with two configure
    runs and two libxxx.la creates, one for the variant A (e.g.
    32bit off_t) and the other for variant B (e.g. 64bit off_t).
    
    I do differentiate them currently by telling them some
    "-release A" suffix - that works for both .so and .dll
    files, as the result will be a libxxx-A.so.0 and some
    libxxx-A.dll. But both variant-builds will still share
    a common name - libxxx.so and libxxx.a. 

(*) I did really think about submitting a patch to be able
    to register a suffix for the big defaults too, but now Ralph
    makes me think if that would not be a bit short-sighted.
    I start to think that the computations of install-names
    from their .la targets should be reworked at a larger scale.

    Looking at the install-step, it could also take a look for
    some of the problems of post-install re-linking which I remember 
    to have been doing the wrong thing in some DESTDIR setups (was
    that with modules linking to their parent lib? well, perhaps it
    is already resolved, I've avoided that one for a looong time)

atleast, I guess that there is no quick solution, isn't it, Robert?

Es schrieb Robert Boehne:
> 
>   It wouldn't be much trouble to allow Libtool to create
> libraries with any extention you tell it, but it is more
> complex than hacking your Makefile.am.  I don't recall seeing
> a patch being posted, correct me if I'm wrong.
>   The other request however, isn't feasable.  Libtool needs to
> create non-pic objects when linking static libs, pic objects when
> linking shared libs.  Libtool can't wait until link time to decide
> to not link static libs, it has to know at configure time.
> Anyway, what is the problem with what Libtool currently does?
> Couldn't you either configure to not build static, or simply
> ignore the static version?
> 
> > [...]
> > To make life easier, I would be nice if Libtool provides the following
> > additional features:
> >
> >  * A link flag for Libtool to suppress generation of a static
> >    library on a per target basis.  The --disable-static option
> >    for configure is not what I want.
> >
> >  * A link flag for Libtool to specify a different installation
> >    file name for a module.
> >