[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Integration of a Perl XS module with an Automake build system
From: |
Gavin Smith |
Subject: |
Re: Integration of a Perl XS module with an Automake build system |
Date: |
Tue, 30 Jun 2015 23:31:43 +0100 |
On 30 June 2015 at 23:06, Bob Friesenhahn <address@hidden> wrote:
> On Tue, 30 Jun 2015, Gavin Smith wrote:
>>
>>
>> What you say about using a different compiler is worrying, though, and
>> I hadn't thought about it before. So basically when compiling an XS
>> module, you need to use whatever compiler was used to compile perl in
>> the first place? I think we could retrieve this information and use it
>> only when compiling the XS module, allowing the rest of the program to
>> be compiled with the compiler that the configure script or user
>> chooses.
>
>
> If you use a system which supports several completely different compilers
> targeting the same ABI, you immediately find dismay unless you compile
> Python using the same compiler you plan to use.
>
> This is quite evident on Solaris systems which use the Sun/Oracle compiler
> to build the bundled Python so it produces Sun compiler options which don't
> work with GCC.
Assuming the same problem exists with Perl, then the only solution to
this I can think of is to generate the compiler options we need
automatically. Hopefully libtool can do this, and the diversity among
the ways that Perl can be compiled isn't so great that we are left in
the position of trying to convert from the compiler flags that Perl
was compiled with to the compiler flags of another compiler. If the
ABI is the same, it should be possible for Perl to load in a properly
compiled shared library object.
Through a process of elimination, I've found that the flag that made
the difference in my case was -D_FILE_OFFSET_BITS=64. Without this I
get:
Not a CODE reference at Texinfo/Convert/XSParagraph/lib/XSParagraph.pm line 83.
END failed--call queue aborted at
Texinfo/Convert/XSParagraph/lib/XSParagraph.pm line 83.
Compilation failed in require at Texinfo/Convert/Plaintext.pm line 34.
BEGIN failed--compilation aborted at Texinfo/Convert/Plaintext.pm line 34.
Compilation failed in require at Texinfo/Convert/Info.pm line 25.
BEGIN failed--compilation aborted at Texinfo/Convert/Info.pm line 25.
Compilation failed in require at ./texi2any.pl line 115.
BEGIN failed--compilation aborted at ./texi2any.pl line 115.
It still worked when I removed other flags like "-fstack-protector",
so hopefully as long as _FILE_OFFSET_BITS and maybe a few other
symbols are defined to the same values as when Perl was compiled,
everything will work.
> Not specifically when cross-compiling. Perl has a particular way to name the
> directories in which it puts the module in the build tree and installation
> tree. Part of this includes the basic architecture of the machine (as known
> to Perl).
As long as we use the directory layout Perl is expecting, everything
should be fine, right?