On Thu, 31 Dec 2009, Antonio Diaz Diaz wrote:
BTW, I am thinking about disabling the build of shared libraries by default.
The usual reasons for shared libs [0] aside, this will certainly increase
portability, because it explicitly makes shared linking a task for
packagers. Wherever shared linking is available, its benefits detailed
under [0] can still be harnessed by packagers.
(This happens to match my approach to upstream vs. packaged sources:
whatever is portable (hopefully supported by standards) goes into
upstream; anything implementation-dependent goes into the packaging.)
Furthermore, quoting from the bzip2-1.0.5 [1] README,
bzip2-shared, a client of the shared library, is also built, but
not self-tested. So I suggest you also build using the normal
Makefile, since that conducts a self-test. A second reason to
prefer the version statically linked to the library is that, on x86
platforms, building shared objects makes a valuable register (%ebx)
unavailable to gcc, resulting in a slowdown of 10%-20%, at least
for bzip2.
This may or may not be relevant here.
One more thing. Plzip 0.1 only works with lzlib 0.7. The next version of
plzip (0.2) will only work with lzlib 0.8-rc2 or newer.
I'm not sure about your plans with plzip-0.2, but please consider
reimplementing the functionality of the SIZES macro, as plzip allows the
user to manually configure the dictionary size, possibly making the
invariants established in llzip invalid. I'm sure you remember the
cheerful thread containing [2] :) Again, thank you, John, for looking at
the source.
Cheers,
lacos
[0] http://people.redhat.com/drepper/no_static_linking.html
[1] http://bzip.org/downloads.html
[2] http://lists.gnu.org/archive/html/lzip-bug/2009-12/msg00013.html
_______________________________________________
Lzip-bug mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/lzip-bug
