Front page | perl.perl5.porters |
Postings from April 2011
On Wed, Apr 27, 2011 at 4:39 PM, Niko Tyni <ntyni@debian.org> wrote:
> Failed 4 tests out of 2037, 99.80% okay.
> ../cpan/Module-Build/t/xs.t
> ../dist/ExtUtils-ParseXS/t/basic.t
> ../dist/ExtUtils-ParseXS/t/more.t
> ../dist/ExtUtils-ParseXS/t/usage.t
>
> What's happening seems to be that when CFLAGS is set, it overrides
> other flags in ExtUtils::CBuilder. One of these, -D_FILE_OFFSET_BITS=64,
> is apparently crucial on this platform for some reason.
> Bisecting shows the crucial thing that breaks this is
> -D_FILE_OFFSET_BITS=64 missing. Don't know why.
> It looks like this is a change in ExtUtils::CBuilder, maybe
> https://github.com/dagolden/extutils-cbuilder/commit/e653d24a
I doubt there's anything crucial about the particular flag, but rather
it's the fact that you're building extensions using flags that give
you code that is binary incompatible with the perl binary it's being
built against. It looks like your expectation is that you can add an
optimization flag by specifying only that flag in CFLAGS. Sounds
reasonable, but clearly what EU::CB is doing is dropping everything it
got from $Config{ccflags} and replacing rather than supplementing it
with what you gave it in CFLAGS.
With options like -D_LARGEFILE_SOURCE and -D_FILE_OFFSET_BITS=64' used
to build Perl but dropped when testing extension building, you could
be getting a different and incompatible stat structure or other binary
incompatible differences between the extension and the Perl core.
It seems like the principle of least surprise might be to make EU::CB
take CFLAGS as a supplement to $Config{ccflags} rather than as a
replacement. It would still be possible to create binary
incompatibilities, but perhaps less likely.
Thread Previous