Re: [JITTER] PIC code in sub-package mode

[Jose E. Marchesi]

    > patches that makes poke to build a shared library libpoke.so and an
    > executable `poke', that links to the shared library.
    >
    > Our problem now is that the jitter sub-package mode provides an archive
    > libjitter-VARIANT.a that contains objects built as non-PIC.  This is
    > what is placed in $(JITTER_LDADD).
    >
    > We would need for jitter to also provide a $(JITTER_LIBADD) expanding to
    > a convenience library providing objects built as PIC, that we can
    > include in libpoke_la_LIBADD.
    
    I have a solution in mind.
    
    There should be two ways of linking the Jitter runtime: a libtool way,
    and a non-libtool way.  This is desirable because some package relying
    on Jitter may use Libtool, while others will not.  There would be one
    different Autoconf substitution / shell variable for each variant.
    
    The fact that your problem, forcing PIC code, can be solved by using
    Libtool to me is a reminder of the need for a good solution, but is not
    really related.  Are Libtool convenience libraries always PIC?  I doubt
    it.  (In fact I would say that static libraries have good reasons *not*
    to be PIC, for performance's sake).  This seems like a solution by
    accident.

Libtool convenience libraries can be incorporated in both applications
and shared objects (using LDADD and LIBADD respectively), so I guess the
libfoo.la contains pointers to both PIC and non-PIC code.