On 02/11/2012 02:24, Marvin Humphrey wrote:
I see from your comment on <https://issues.apache.org/jira/browse/LUCY-211>
that we have a workaround for these. (Redefining `for`, oi...)
The next step is to make CFC use Charmonizer. We might want to create a
separate ticket for that.
Maybe that's base.pm prior to 2.18 misbehaving? That error message indicates
that the superclass was not loaded.
$ perl -le 'package Foo; Foo->SUPER::new'
Can't locate object method "new" via package "Foo::SUPER" at -e line 1.
Should we make this change to Lucy::Build?
-use base qw( Clownfish::CFC::Perl::Build );
+use Clownfish::CFC::Perl::Build;
+BEGIN { push our @ISA, 'Clownfish::CFC::Perl::Build' }
I have no idea. I also couldn't reproduce it with ActivePerl
5.16.1.1601, 32-bit.
I think this problem may have gone away in trunk as a side effect of recent
changes to Charmonizer. The problem occurs during the linking phase for
Charmonizer, but that linking phase is handled a different way now that
Charmonizer gets bundled up into a single amalgamated C file. Compiling
charmonizer during Lucy's Perl build is now one simple command (which doesn't
use any of the libs specified by the Perl Config module):
cl charmonizer.c /Fecharmonize.exe
That linking bug you reported may come back during another linking phase,
though -- like when we try to link together Lucy.dll from all the *.obj files.
I think it's something else. IIRC the problem that I had when building
Lucy with 64-bit ActivePerl some months ago was that it tried to link
against bufferoverflowU.lib which wasn't present on my system. That's
what my bug report is about.
From what I understand bufferoverflowU.lib is only needed with the
Windows Server 2003 Platform SDK compiler which is what ActiveState uses
for 64-bit builds.
The easiest solution might be to compile with /GS- which should disable
buffer overrun protection completely. Otherwise Charmonizer has to check
whether linking against that library is needed.
Nick
