You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucy.apache.org by Nick Wellnhofer <we...@aevum.de> on 2012/11/01 20:18:55 UTC
[lucy-dev] ActiveState PPM build failures
I had a deeper look into the ActiveState PPM failures, and they're not related to MSVC6 as I assumed on lucy-user. It would be really nice to make the PPM build work.
32-bit, Perl 5.12 and 5.14
--------------------------
http://ppm4.activestate.com/MSWin32-x86/5.12/1200/L/LO/LOGIE/Lucy-0.3.2.d/log-20120710T215703.txt
http://ppm4.activestate.com/MSWin32-x86/5.14/1400/L/LO/LOGIE/Lucy-0.3.2.d/log-20120711T022317.txt
This is the same problem that was reported here:
http://mail-archives.apache.org/mod_mbox/lucy-user/201109.mbox/%3c662C6E983E7C4874833424B8642F2779@teddy%3e
No idea what's going on there but note that the "/TP" flag (C++ mode) won't appear on the command line because it should be in the ".ccs" compiler script.
32-bit, Perl 5.16
-----------------
http://ppm4.activestate.com/MSWin32-x86/5.16/1600/L/LO/LOGIE/Lucy-0.3.2.d/log-20120816T225009.txt
"Can't locate object method "new" via package "Lucy::Build::SUPER" at buildlib/Lucy/Build.pm line 143."
Strange…
64-bit, Perl 5.12, 5.14 and 5.16
--------------------------------
http://ppm4.activestate.com/MSWin32-x64/5.12/1200/L/LO/LOGIE/Lucy-0.3.2.d/log-20120710T212100.txt
http://ppm4.activestate.com/MSWin32-x64/5.14/1400/L/LO/LOGIE/Lucy-0.3.2.d/log-20120711T021911.txt
http://ppm4.activestate.com/MSWin32-x64/5.16/1600/L/LO/LOGIE/Lucy-0.3.2.d/log-20120813T075017.txt
Charmonizer build fails with "unresolved external symbol __security_check_cookie"
I think this is related to the following bug that I reported to ActiveState:
http://bugs.activestate.com/show_bug.cgi?id=93797
Nick
Re: [lucy-dev] ActiveState PPM build failures
Posted by Nick Wellnhofer <we...@aevum.de>.
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
Re: [lucy-dev] ActiveState PPM build failures
Posted by Marvin Humphrey <ma...@rectangular.com>.
On Thu, Nov 1, 2012 at 12:18 PM, Nick Wellnhofer <we...@aevum.de> wrote:
> I had a deeper look into the ActiveState PPM failures, and they're not
> related to MSVC6 as I assumed on lucy-user. It would be really nice to make
> the PPM build work.
+1
Thanks for looking into this, Nick!
> 32-bit, Perl 5.12 and 5.14
> --------------------------
>
> http://ppm4.activestate.com/MSWin32-x86/5.12/1200/L/LO/LOGIE/Lucy-0.3.2.d/log-20120710T215703.txt
> http://ppm4.activestate.com/MSWin32-x86/5.14/1400/L/LO/LOGIE/Lucy-0.3.2.d/log-20120711T022317.txt
>
> This is the same problem that was reported here:
>
> http://mail-archives.apache.org/mod_mbox/lucy-user/201109.mbox/%3c662C6E983E7C4874833424B8642F2779@teddy%3e
>
> No idea what's going on there but note that the "/TP" flag (C++ mode) won't appear on the command line because it should be in the ".ccs" compiler script.
I see from your comment on <https://issues.apache.org/jira/browse/LUCY-211>
that we have a workaround for these. (Redefining `for`, oi...)
> 32-bit, Perl 5.16
> -----------------
>
> http://ppm4.activestate.com/MSWin32-x86/5.16/1600/L/LO/LOGIE/Lucy-0.3.2.d/log-20120816T225009.txt
>
> "Can't locate object method "new" via package "Lucy::Build::SUPER" at buildlib/Lucy/Build.pm line 143."
>
> Strange…
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' }
> 64-bit, Perl 5.12, 5.14 and 5.16
> --------------------------------
>
> http://ppm4.activestate.com/MSWin32-x64/5.12/1200/L/LO/LOGIE/Lucy-0.3.2.d/log-20120710T212100.txt
> http://ppm4.activestate.com/MSWin32-x64/5.14/1400/L/LO/LOGIE/Lucy-0.3.2.d/log-20120711T021911.txt
> http://ppm4.activestate.com/MSWin32-x64/5.16/1600/L/LO/LOGIE/Lucy-0.3.2.d/log-20120813T075017.txt
>
> Charmonizer build fails with "unresolved external symbol __security_check_cookie"
>
> I think this is related to the following bug that I reported to ActiveState:
>
> http://bugs.activestate.com/show_bug.cgi?id=93797
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.
Marvin Humphrey