Packaging thread safe version of libraries
Thanks for the suggestions.
So what I'm going to do is:
* Enable multithread support. Check with packagers of dependent
software if they find any problem.
* If there is any problem provide the two libraries
* if not, provide just the multithreaded version
2011/10/29 Thomas Spura <email@example.com>:
> On Fri, 28 Oct 2011 22:49:52 -0400
> Tom Lane wrote:
>> Thomas Spura <firstname.lastname@example.org> writes:
>> > Sergio Pascual wrote:
>> >> So I was wondering if it's a good idea to compile the code twice
>> >> and distribute two versions of the library, libcfitsio.so and
>> >> libcfitsio-mt.so. This implies to distribute two pkg-config files,
>> >> cfistio.pc and cfitsio-mt.pc
>> > Completely replacing the library with a thread safe version
>> > would make the library slower, when using without threads. Don't
>> > know if that's a big issue here?
>> FWIW, I think that's mostly a twentieth-century problem. *With modern
>> toolchains and libraries there isn't likely to be much difference.
> It depends on the use case. When this library is called very often in
> an HPC environment, it matters, if your program is running 10% slower
> or not (I once had such a problem, when writing my own pseudo random
> number generator.).
>> I would suggest taking a negative approach: do not ship the
>> non-thread-safe version unless you have positive evidence that it's
>> meaningfully faster, or there's a known incompatibility in the
>> thread-safe version. *It only takes one episode of debugging an
>> oh-you-should-have-used-the-thread-safe-version problem to wipe out
>> any possible benefit from using a not-thread-safe-version, when you
>> account for person-hours saved or wasted by each.
>> To give a concrete example: there is no non-thread-safe version of
>> glibc in Fedora.
> I agree. IO is slow anyways, so it's unlikely that users are hit badly
> by a slightly slower library. (But still don't know the use case of it,
> so it's up to the maintainer which way to go.)
> * * * *Tom
> packaging mailing list
Sergio Pascual * * * * * * * * * * * *http://guaix.fis.ucm.es/~spr
gpg fingerprint: 5203 B42D 86A0 5649 410A F4AC A35F D465 F263 BCCC
Departamento de Astrofísica -- Universidad Complutense de Madrid (Spain)
packaging mailing list