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 Regards, Sergio 2011/10/29 Thomas Spura <tomspur@xxxxxxxxxxxxxxxxx>: > On Fri, 28 Oct 2011 22:49:52 -0400 > Tom Lane wrote: > >> Thomas Spura <tomspur@xxxxxxxxxxxxxxxxx> 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 > packaging@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/packaging -- 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 packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
