Many of you are familiar with the error during `make' of recent pugs:
In file included from /usr/lib/perl/5.8/CORE/op.h:496,
/usr/lib/perl/5.8/CORE/reentr.h:611: error: field `_crypt_struct' has incomplete type
In file included from /usr/lib/perl/5.8/CORE/perl.h:3793,
/usr/lib/perl/5.8/CORE/pp.h:134:1: warning: "RETURN" redefined
In file included from /usr/include/readline/keymaps.h:36,
/usr/include/readline/chardefs.h:120:1: warning: this is the location of the previous definition
In file included from /usr/lib/perl/5.8/CORE/perl.h:3813,
/usr/lib/perl/5.8/CORE/proto.h:199: error: parse error before "off64_t"
/usr/lib/perl/5.8/CORE/proto.h:201: error: parse error before "Perl_do_sysseek"
/usr/lib/perl/5.8/CORE/proto.h:201: error: parse error before "off64_t"
/usr/lib/perl/5.8/CORE/proto.h:201: warning: type defaults to `int' in declaration of `Perl_do_sysseek'
/usr/lib/perl/5.8/CORE/proto.h:201: warning: data definition has no type or storage class
/usr/lib/perl/5.8/CORE/proto.h:202: error: parse error before "Perl_do_tell"
/usr/lib/perl/5.8/CORE/proto.h:202: warning: type defaults to `int' in declaration of `Perl_do_tell'
/usr/lib/perl/5.8/CORE/proto.h:202: warning: data definition has no type or storage class
/usr/lib/perl/5.8/CORE/proto.h:1308: error: parse error before "Perl_PerlIO_tell"
/usr/lib/perl/5.8/CORE/proto.h:1308: warning: type defaults to `int' in declaration of `Perl_PerlIO_tell'
/usr/lib/perl/5.8/CORE/proto.h:1308: warning: data definition has no type or storage class
/usr/lib/perl/5.8/CORE/proto.h:1309: error: parse error before "off64_t"
Dave Rolsky noted today that running `make unoptimised' will get the
compilation process to pass src/Pugs/Embed/Perl5.hs without giving that
error. This is a useful workaround.
Also some have observed that this only seems to happen on systems with
more than one perl installed; this applies me, but I can't explain it
yet, as I take all references to my non-system-installed Perls out of
my PATH (and they're not in /usr/local, anyway).
Digging deeper into the make process, I found that it is succeeding
without optimisation because the `-O0' switch tells ghc to compile the
C to assembly code (-fasm), rather than getting gcc to (-fvia-C).
To track this down, I first replaced src/Pugs/Embed/Perl5.hs with
something a lot more minimal;
module Pugs.Embed.Perl5 where
I also replaced src/perl5/perl5.h with the minimal;
However, this basic stub still fails.
Re-running the command, but with -O0 and -fvia-C, as well as
'-v -keep-tmp-files', I was able to obtain the input C files to gcc
and the full gcc command used to compile it. At least this yields a way
to get the full, preprocessed input to gcc for debugging and check that
all included files are from /usr/include and not any of my custom Perl
However I have been unable to figure out what exactly is going on.
I'm guessing that the problem lies in the defines passed to gcc; though
passing it -D__USE_LARGEFILE64=1 -D__USE_FILE_OFFSET64=1 didn't seem to
make any difference.
Has anyone got any more information to add to this problem? I'm
particularly interested to know which platforms it affects.
It seems to affect Debian and derivatives (including my distribution,
Ubuntu). I'm seeing it on both my x86 laptop and my AMD64 desktop.
My x86/Gentoo server is unaffected.
Brent 'Dax' Royal-Gordon <br...@brentdax.com>
Perl and Parrot hacker
I just got a note from someone on FC3, who said they also have the
problem. Seems restricted to GNU/Linux so far.
This hasn't been a problem for me on Mac OS 10.4 with 3 installed
versions of perl5.