[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [JITTER] PIC code in sub-package mode
From: |
Jose E. Marchesi |
Subject: |
Re: [JITTER] PIC code in sub-package mode |
Date: |
Sun, 17 May 2020 20:04:09 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
> 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.