Thread: Compiler options for plperl

Hi,

applications that use Perl as embedded interpreter should be compiled
with the same compiler flags that were used to compile the perl shared
library itself. The attached patch fixes this.

cu
    Reinhard

Reinhard Max <max@suse.de> writes:
> applications that use Perl as embedded interpreter should be compiled
> with the same compiler flags that were used to compile the perl shared
> library itself. The attached patch fixes this.

Unfortunately, this goes down the same dead-end path we went down three
or four releases ago.  If we try to do the above then we must also use
the same compiler that was used for Perl.  For example, your patch will
instantly blow up on my system where Perl is built with HPUX's cc (per
its default configuration) and Postgres is built with gcc (also its
default choice) --- the compiler switches aren't even slightly alike.

Please explain the problem you're trying to solve, rather than offering
an unworkable patch with no explanation.

            regards, tom lane

On Thu, 31 Oct 2002 at 12:11, Tom Lane wrote:

> If we try to do the above then we must also use the same compiler
> that was used for Perl.  For example, your patch will instantly blow
> up on my system where Perl is built with HPUX's cc (per its default
> configuration) and Postgres is built with gcc (also its default
> choice) --- the compiler switches aren't even slightly alike.

I see.

Would it work for you, if only the preprocessor macro definitions were
derived from perl?

Here I get:

$ perl -MConfig -e 'print $Config{ccflags}'
-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64


> Please explain the problem you're trying to solve, rather than
> offering an unworkable patch with no explanation.

While I tried to compile PostgreSQL-7.3b3, I got:

gcc -O2 -g -fPIC -I.
-I/usr/lib/perl5/5.8.0/x86_64-linux-thread-multi/CORE
-I../../../src/include   -c -o plperl.o plperl.c
In file included from
/usr/lib/perl5/5.8.0/x86_64-linux-thread-multi/CORE/op.h:480,
                 from
/usr/lib/perl5/5.8.0/x86_64-linux-thread-multi/CORE/perl.h:2209,
                 from plperl.c:61:
/usr/lib/perl5/5.8.0/x86_64-linux-thread-multi/CORE/reentr.h:602:
field `_crypt_struct' has incomplete type
/usr/lib/perl5/5.8.0/x86_64-linux-thread-multi/CORE/reentr.h:747:
confused by earlier errors, bailing out
make[3]: *** [plperl.o] Error 1

Adding -D_GNU_SOURCE to the gcc command line fixed this (crypt.h only
declares "struct crypt_data" when _GNU_SOURCE is defined). Our Perl
maintainer told me then, that these definitions should always be
fetched from Perl itself to be on the safe side.

cu
    Reinhard

Reinhard Max <max@suse.de> writes:
> Would it work for you, if only the preprocessor macro definitions were
> derived from perl?

I guess that's reasonable -- at least it should solve the Perl 5.8.0
problems, which is the only thing requiring immediate attention.

Provided no one else objects, can you send in a patch for this? IMHO
we should have a fix for the Perl problems in 7.3, in one form or
another.

Cheers,

Neil

--
Neil Conway <neilc@samurai.com> || PGP Key ID: DB3C29FC

Hi,

On 4 Nov 2002 at 18:04, Neil Conway wrote:

> Provided no one else objects, can you send in a patch for this? IMHO
> we should have a fix for the Perl problems in 7.3, in one form or
> another.

here it comes...

cu
    Reinhard

Reinhard Max writes:

> Would it work for you, if only the preprocessor macro definitions were
> derived from perl?

Nope.  I don't want to trust anything that comes from Perl.

Why not just define _GNU_SOURCE in some strategic place?  (But please not
on the command line.)

--
Peter Eisentraut   peter_e@gmx.net

On Tue, 5 Nov 2002 at 23:41, Peter Eisentraut wrote:

> Reinhard Max writes:
>
> > Would it work for you, if only the preprocessor macro definitions were
> > derived from perl?
>
> Nope.  I don't want to trust anything that comes from Perl.

Me neither, but I think there is no other chance.

> Why not just define _GNU_SOURCE in some strategic place?  (But
> please not on the command line.)

As far as I understood our Perl guy, anything that embeds Perl _has_
to (or at least _should_) be compiled with the same preprocessor
defines. It might depend on the platform and compile-time
configuration of Perl which defines are needed for a particular
installation.

So why not let Perl itself tell what switches it needs?


cu
    Reinhard