GD is notoriously hard to build.  That's why it was left out in the first place.  Can you explain why you need it there?

I'm trying to test the RPM on Mandriva.  For some reason, they include a non-threaded perl so the binary perl modules need to be rebuilt.

This is also happening on Gentoo (I'm currently trying to create a Portage ebuild (aka package) for SqueezeCenter 7). I've raised this in bug 6389 but have been pointed to this as a duplicate.

For Gentoo the same ebuild (which is essentially a shell script that compiles and installs a package) is universal for a number of different architectures (eg x86/mips/ppc/arm etc etc). Because it can't dictate the arch in use, nor other things such as whether Perl is compiled for threading or not, the noarch SC7 tarball is required. This means the Perl modules need to be compiled.

GD is a dependency for SC7 so hopefully it can be built in build-perl-modules. I can work around this by pulling in GD as a dependency of the ebuild, but I think it would be better to be consistent with the other modules I think. Is it really more complicated than adding it to build-perl-modules? I know it relies on libgd but I can ensure that the Gentoo package will install that before calling build-perl-modules.

Will look at this post-7.0.

*** Bug 6389 has been marked as a duplicate of this bug. ***

I wonder if this can still be considered now we're some way past 7.0? It's a cause of Gentoo bug 237548 (http://bugs.gentoo.org/show_bug.cgi?id=237548), for example.

On NetBDS, this is also the best way I found in order to have squeezecenter working.

I installed libgd with the ports and perl module with build-perl-modules.pl (by adding:   'GD'=> 'GD-2.35.tar.gz ).

So, I doesn't need to install any perl module with the ports. If I use the ports (an up-to-date ports), I have many version numbers mismatch and some problem with JSON, HTTP...etc.

Andy,

I can't test it right now, but I assume change 25654 means this can be closed?

Yep, it's in there now.