Bug#430805: The problem is caused by Image::LibRSVG->isGzCompressionSupported

[Niko Tyni]

On Wed, Jun 27, 2007 at 12:03:20PM -0500, Gunnar Wolf wrote:

> ...I reproduced it - the problem is that $rsvg->loadImage with a
> svg.gz triggers a segfault, and all the tests from that point on don't
> get executed at all. Just to illustrate, from the source tree, just
> after the build died (hence with the compiled module in blib/):
> 
> $ perl -Iblib/lib -Iblib/arch -e 'use Image::LibRSVG; $rsvg=Image::LibRSVG->new; print $rsvg->loadImage("examples/artscontrol.svg.gz")'
> 
> triggers basically the same message as the one reported in the
> bug. 

The regression here is that libgsf 1.114.4-1 introduced changes
that broke applications not calling gsf_init() and using 'dynamic'
stream types like gzipped input.

This is #431104, and I'll send more details there.

In this case, libgsf is used by librsvg, which calls gsf_init() from
rsvg_init(). So instead of disabling .svgz support, we should just call
rsvg_init() from the constructor. Patch attached; this fixes the test
failures for me.

I'll forward this upstream as well.

> Now, the faulty function seems to be
> Image::LibRSVG->isGzCompressionSupported - In fact, it is not even
> documented, and the build does not depend on (nor ever mention)
> Perl's Compress::Zlib or C's zlib. This function is not even
> documented in the POD or used anywhere else in the code:

I think Image::LibRSVG->isGzCompressionSupported() is just an internal
function to make it easier to disable .svgz support if needed. The zlib
linkage comes from libgsf through librsvg.

Cheers,
-- 
Niko Tyni   ntyni at iki.fi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 430805.patch
Type: text/x-diff
Size: 231 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/pkg-perl-maintainers/attachments/20070703/c07d603e/attachment-0001.patch