Re: build problems with latest cvs



pcg goof com ( Marc) (A.) (Lehmann ) said:
When building from latest cvs, I get:

   Gtk2 object version 1.011 does not match bootstrap parameter 1.030 at
   /opt/perl/lib/perl5/DynaLoader.pm line 249.

This problem probably comes because ParseXSDoc is being called _before_ the
shared object is being build, thus the command:

   /localvol/opt/perl/bin/perl -I blib/lib -I blib/arch -MGlib::ParseXSDoc

ParseXSDoc doesn't 'use Gtk2' (or at the very least shouldn't be) it's part of
Glib and only parses XS files creating the build/doc.pl file. which doesn't
require use of Gtk2 at all.

Picks up the installed .so, not the to-be-build. Restarting make works,
which indicates that it might be a missing dependency on the Gtk2.so.

Here is a partial build log up to the point where it stops:
...
"xs/PangoTabs.xs", "xs/GdkDisplay.xs", "xs/GdkDisplayManager.xs",
"xs/GdkScreen.xs", "xs/GtkClipboard.xs")' > build/doc.pl
   chmod 644 Gtk2.bs
   /localvol/opt/perl/bin/perl -I blib/lib -I blib/arch
tools/podifystockitems.pl > build/stock_items.podi
   Gtk2 object version 1.011 does not match bootstrap parameter 1.030 at
/opt/perl/lib/perl5/DynaLoader.pm line 249.
   Compilation failed in require at tools/podifystockitems.pl line 6.
   BEGIN failed--compilation aborted at tools/podifystockitems.pl line 6.
   make: *** [build/stock_items.podi] Error 2
   make: *** Waiting for unfinished jobs....
   Deleting Gtk2::Allocation from doc.pl's $data

The Gtk2.so is indeed not built at this point.

podifystockitems.pl is the point at which things die rather than ParseXSDoc.
it does indeed require Gtk2 to be working (at least in the blib dir,) but it
should not be run until the pod2man step which (on linux/x86) is after all of
the compilation as part of manifying things. podifystockitems.pl is run as
part of the GenPod step(s) and is invoked by using POD_DEPENDS, @gen_pods is a
list of all of the autogen'd .pod files. before we make them, we require that
the things in POD_DEPENDS are done.

what arch was this one, perhaps different versions of ExtUtils::MakeMaker
and/or make are exhibiting different behaviors? i can't seem to reproduce this
problem with a make, or even make <some-specific-rule> when i have an old
version installed and building from clean. if it turns out to be necessary to
have POD_DEPENDS depend on the pm and so being in the blib dirs that should be
doable, but i'd rather have a better understanding of what happened first.

-rm



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]