Bug#752965: libwx-glcanvas-perl: FTBFS - configure check fails to detect wxWidgets

Niko Tyni ntyni at debian.org
Mon Aug 11 19:57:59 UTC 2014


clone 752965 -1
retitle -1 libwx-perl: embeds exact wxWidgets version, needs stricter dependencies
reassign -1 libwx-perl 1:0.9923-1
submitter -1 !
thanks

On Sat, Jun 28, 2014 at 03:40:05PM +0200, gregor herrmann wrote:
> On Sat, 28 Jun 2014 01:41:03 +0100, Michael Tautschnig wrote:
> 
> >    dh_auto_configure
> > Searching configuration for:
> > wxWidgets (any version) for (any toolkit); compiler compatibility: (any compiler) (any version);
> > 
> > Available configurations:
> > wxWidgets 3.000001 for gtk2; compiler compatibility: gcc 3.4; options: no debug, unicode, no mslu
> > dh_auto_configure: perl Makefile.PL INSTALLDIRS=vendor OPTIMIZE=-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 LD=cc -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wl,-z,relro returned exit code 2
> > debian/rules:4: recipe for target 'build' failed
> > make: *** [build] Error 2
> 
> The message and the die() come from Alien::wxWidgets:

> But then I'm not sure why this is happening ...                                                                                 

libwx-perl embeds the exact wxwidgets version in
 /usr/lib/perl5/Wx/Mini.pm:our $alien_key = 'gtk2_3_0_0_uni_gcc_3_4';
 /usr/lib/perl5/Wx/build/Opt.pm:  'alien_key' => 'gtk2_3_0_0_uni_gcc_3_4',

and libalien-wxwidgets-perl in

 /usr/lib/perl5/Alien/wxWidgets/Config/gtk2_3_0_1_uni_gcc_3_4.pm:package Alien::wxWidgets::Config::gtk2_3_0_1_uni_gcc_3_4;
 /usr/lib/perl5/Alien/wxWidgets/Config/gtk2_3_0_1_uni_gcc_3_4.pm:          'alien_package' => 'Alien::wxWidgets::Config::gtk2_3_0_1_uni_gcc_3_4',
 /usr/lib/perl5/Alien/wxWidgets/Config/gtk2_3_0_1_uni_gcc_3_4.pm:          'alien_base' => 'gtk2_3_0_1_uni_gcc_3_4',

When those don't match, as is the case with current sid, Wx::build::MakeMaker breaks:
 % perl -MWx::build::MakeMaker -e "wxWriteMakefile(NAME => 'My::Module', VERSION_FROM => 'Module.pm' ); "; echo $?
 Searching configuration for:
 wxWidgets (any version) for (any toolkit); compiler compatibility: (any compiler) (any version); 
 
 Available configurations:
 wxWidgets 3.000001 for gtk2; compiler compatibility: gcc 3.4; options: no debug, unicode, no mslu
 2

Such specific version requirements don't seem very elegant.  I don't
really know if it's reasonable to expect the minor part of the version
number to always match, or if it could be left out of the key names,
but that's upstream domain.

For the time being, I suppose we need to make the dependencies in libwx-perl
stricter in the same style as we already do with libalien-wxwidgets-perl. FWIW
the current situation is

Package: libalien-wxwidgets-perl
Depends: perl, libwxgtk3.0-dev (>= 3.0.1-1), libwxgtk3.0-dev (<< 3.0.2~), libwxgtk-media3.0-dev (>= 3.0.1-1), libwxgtk-media3.0-dev (<< 3.0.2~), perlapi-5.18.2, libmodule-pluggable-perl | perl (<< 5.17.0)

Package: libwx-perl
Depends: perl (>= 5.18.2-2+b1), perlapi-5.18.2, libc6 (>= 2.14), libgcc1 (>= 1:4.1.1), libwxbase3.0-0 (>= 3.0.0), libwxgtk-media3.0-0 (>= 3.0.0), libwxgtk3.0-0 (>= 3.0.0), libalien-wxwidgets-perl (>= 0.65+dfsg~)

I see the current libwx* dependencies come from dpkg-shlibdeps, so I'm
not sure what's the best way to achieve a (<< next~) pair for them all.

Anyway, cloning a bug against libwx-perl.

libwx-glcanvas-perl itself is not at fault and will start to build
again when libwx-perl has been rebuilt, probably next week with the Perl
5.20 transition. #752965 can be closed at that point.
-- 
Niko Tyni   ntyni at debian.org



More information about the pkg-perl-maintainers mailing list