In article <20031007214733.A4494@vaasje.org>,
Frank van der Linden <fvdl@netbsd.org> wrote:
>On Mon, Oct 06, 2003 at 02:43:23PM +0200, Aymeric Vincent wrote:
>> If I understand correctly, the point of using (PIC) static libraries
>> instead of shared libraries is that you can replace the API of the
>> library at any point in time without bothering about keeping binary
>> compatibility for software compiled with a former version of the API.
>> 
>> And for whatever reason, XF86 people want to keep the freedom of
>> changing their API for a few libraries. I think we should cooperate
>> with them in this respect instead of following the wrong move of
>> several Linux vendors.
>
>Using PIC .a files is ugly.. I'm not sure if I see the versioning issue,
>since several other libraries have had their major numbers bumped
>over time.

I totally agree here. Using _pic.a files a horrible kludge and not
at all the intended use of the _pic.a files.

>Are these pic_a libaries linked into others as dependencies? What are the
>chances of the interface changing? If the answers to this are "yes" and
>"high", then I'd rather not make these shared libraries, as it means
>that we would have to go through some pain bumping a lot of library
>versions if an interface changes.But otherwise having them shared is cleaner.

I don't think it really matters in this particular case how many major
version bumps we have. In reality they are not going to be many, since
we only update our xsrc tree approximately once per year, and we can
use pkgsrc for providing backwards compatible binary packages.

Using shared libraries is the only clean way to do what we are trying to
do. 

libtool: just say no.

christos