Hi,
On 2022-08-30 09:35:51 -0400, Andrew Dunstan wrote:
> On 2022-08-26 Fr 16:25, Andres Freund wrote:
> > On 2022-08-26 16:00:31 -0400, Tom Lane wrote:
> >> Andrew Dunstan writes:
> >>> On 2022-08-26 Fr 12:11, Tom Lane wrote:
> And if that doesn't help, try -Wl,--export-all-symbols
> >>>
On 2022-08-26 Fr 16:25, Andres Freund wrote:
> Hi,
>
> On 2022-08-26 16:00:31 -0400, Tom Lane wrote:
>> Andrew Dunstan writes:
>>> On 2022-08-26 Fr 12:11, Tom Lane wrote:
And if that doesn't help, try -Wl,--export-all-symbols
>>> worked
> Except that it's only happening for plperl, I'd
Hi,
On 2022-08-26 16:00:31 -0400, Tom Lane wrote:
> Andrew Dunstan writes:
> > On 2022-08-26 Fr 12:11, Tom Lane wrote:
> >> And if that doesn't help, try -Wl,--export-all-symbols
>
> > worked
Except that it's only happening for plperl, I'd wonder if it's possibly
related to our magic symbols
On 2022-08-26 Fr 16:00, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 2022-08-26 Fr 12:11, Tom Lane wrote:
>>> And if that doesn't help, try -Wl,--export-all-symbols
>> worked
> Hmph. Hard to see how that isn't a linker bug. As a stopgap
> to get the farm green again, I propose adding
Andrew Dunstan writes:
> On 2022-08-26 Fr 12:11, Tom Lane wrote:
>> And if that doesn't help, try -Wl,--export-all-symbols
> worked
Hmph. Hard to see how that isn't a linker bug. As a stopgap
to get the farm green again, I propose adding something like
ifeq ($(PORTNAME), cygwin)
SHLIB_LINK
On 2022-08-26 Fr 12:11, Tom Lane wrote:
> Andres Freund writes:
>> On 2022-08-26 10:04:35 -0400, Andrew Dunstan wrote:
>>> On 2022-08-25 Th 18:13, Andres Freund wrote:
Can you try adding just that to the flags for building and whether that
then
allows a LOAD 'plperl' to succeed?
Andres Freund writes:
> On 2022-08-26 10:04:35 -0400, Andrew Dunstan wrote:
>> On 2022-08-25 Th 18:13, Andres Freund wrote:
>>> Can you try adding just that to the flags for building and whether that then
>>> allows a LOAD 'plperl' to succeed?
>> Adding what?
> -Wl,--enable-auto-image-base
And
Hi,
On 2022-08-26 10:04:35 -0400, Andrew Dunstan wrote:
> On 2022-08-25 Th 18:13, Andres Freund wrote:
> >>> Could you show objdump -t of the library? Perhaps once with the flags as
> >>> now,
> >>> and once relinking with the "old" flags that we're now omitting?
> >>
> >> current:
> >>
> >>
>
On 2022-08-25 Th 18:13, Andres Freund wrote:
> Hi,
>
> On 2022-08-25 18:04:34 -0400, Andrew Dunstan wrote:
>> On 2022-08-25 Th 17:47, Andres Freund wrote:
$ egrep '_PG_init|Pg_magic_func' plperl.i
extern __attribute__((visibility("default"))) void _PG_init(void);
extern
Hi,
On 2022-08-25 18:04:34 -0400, Andrew Dunstan wrote:
> On 2022-08-25 Th 17:47, Andres Freund wrote:
> >> $ egrep '_PG_init|Pg_magic_func' plperl.i
> >> extern __attribute__((visibility("default"))) void _PG_init(void);
> >> extern __attribute__((visibility("default"))) const Pg_magic_struct
>
On 2022-08-25 Th 17:47, Andres Freund wrote:
> Hi,
>
> On 2022-08-25 17:39:35 -0400, Andrew Dunstan wrote:
>> On 2022-08-25 Th 09:43, Tom Lane wrote:
>>> Peter Eisentraut writes:
>> In short: if the Cygwin Perl headers redefine PGDLLEXPORT (unlikely)
>> or somehow #define
Hi,
On 2022-08-25 17:39:35 -0400, Andrew Dunstan wrote:
> On 2022-08-25 Th 09:43, Tom Lane wrote:
> > Peter Eisentraut writes:
> In short: if the Cygwin Perl headers redefine PGDLLEXPORT (unlikely)
> or somehow #define "__attribute__()" or "visibility()" into no-ops
> (perhaps
On 2022-08-25 Th 09:43, Tom Lane wrote:
> Peter Eisentraut writes:
In short: if the Cygwin Perl headers redefine PGDLLEXPORT (unlikely)
or somehow #define "__attribute__()" or "visibility()" into no-ops
(perhaps more likely) then we could explain this failure, and that
would
Peter Eisentraut writes:
>>> In short: if the Cygwin Perl headers redefine PGDLLEXPORT (unlikely)
>>> or somehow #define "__attribute__()" or "visibility()" into no-ops
>>> (perhaps more likely) then we could explain this failure, and that
>>> would also explain why it doesn't fail elsewhere.
>
On 25.08.22 02:14, Andrew Dunstan wrote:
In short: if the Cygwin Perl headers redefine PGDLLEXPORT (unlikely)
or somehow #define "__attribute__()" or "visibility()" into no-ops
(perhaps more likely) then we could explain this failure, and that
would also explain why it doesn't fail elsewhere.
I
On 2022-08-24 We 18:56, Tom Lane wrote:
> Andrew Dunstan writes:
>> On 2022-08-24 We 09:30, Tom Lane wrote:
>>> Presumably this is caused by not having
-Wl,--export-all-symbols
>>> which is something we ought to be injecting for ourselves if we
>>> aren't doing anything to export the
Andrew Dunstan writes:
> On 2022-08-24 We 09:30, Tom Lane wrote:
>> Presumably this is caused by not having
>> > -Wl,--export-all-symbols
>> which is something we ought to be injecting for ourselves if we
>> aren't doing anything to export the magic-block constant explicitly.
>> But I too am
On 2022-08-24 We 09:30, Tom Lane wrote:
> Peter Eisentraut writes:
>> This patch has failed on Cygwin lorikeet:
>> CREATE EXTENSION plperl;
>> +ERROR: incompatible library
>> "/home/andrew/bf/root/HEAD/inst/lib/postgresql/plperl.dll": missing
>> magic block
> Presumably this is caused by not
Peter Eisentraut writes:
> This patch has failed on Cygwin lorikeet:
> CREATE EXTENSION plperl;
> +ERROR: incompatible library
> "/home/andrew/bf/root/HEAD/inst/lib/postgresql/plperl.dll": missing
> magic block
Presumably this is caused by not having
> -Wl,--export-all-symbols
which is
On 19.08.22 09:12, Peter Eisentraut wrote:
After analyzing the source code of ExtUtils::Embed's ldopts, I think we
can also do this by subtracting $Config{ldflags}, since
my $linkage = "$ccdlflags $ldflags @archives $ld_or_bs";
and we really just want the $ld_or_bs part. (@archives should be
Andres Freund writes:
> FWIW, while trying to mirror the same logic in meson I learned that the new
> logic removes the rpath setting from the parameters on at least netbsd and
> suse. We'll add them back - unless --disable-rpath is used.
Hmm ... on my shiny new netbsd buildfarm animal, I see:
Hi,
On 2022-08-22 08:37:40 -0700, Andres Freund wrote:
> On 2022-08-22 16:32:36 +0200, Peter Eisentraut wrote:
> > On 20.08.22 23:44, Andres Freund wrote:
> > > On 2022-08-20 16:53:31 -0400, Tom Lane wrote:
> > > > Andres Freund writes:
> > > > > Maybe a daft question: Why do want any of the -l
Hi,
On 2022-08-22 16:31:53 +0200, Peter Eisentraut wrote:
> On 20.08.22 22:44, Andres Freund wrote:
> > Maybe a daft question: Why do want any of the -l flags other than -lperl?
> > With
> > the patch configure spits out the following on my debian system:
> >
> > checking for CFLAGS to compile
Hi,
On 2022-08-22 16:32:36 +0200, Peter Eisentraut wrote:
> On 20.08.22 23:44, Andres Freund wrote:
> > On 2022-08-20 16:53:31 -0400, Tom Lane wrote:
> > > Andres Freund writes:
> > > > Maybe a daft question: Why do want any of the -l flags other than
> > > > -lperl? With
> > > > the patch
On 20.08.22 23:44, Andres Freund wrote:
On 2022-08-20 16:53:31 -0400, Tom Lane wrote:
Andres Freund writes:
Maybe a daft question: Why do want any of the -l flags other than -lperl? With
the patch configure spits out the following on my debian system:
checking for CFLAGS to compile
On 20.08.22 22:44, Andres Freund wrote:
Maybe a daft question: Why do want any of the -l flags other than -lperl? With
the patch configure spits out the following on my debian system:
checking for CFLAGS to compile embedded Perl... -DDEBIAN
checking for flags to link embedded Perl...
Hi,
FWIW, looks like Peter's patch unbreaks building plperl on AIX using gcc and
system perl. Before we picked up a bunch of xlc specific flags that prevented
that.
before:
checking for flags to link embedded Perl... -brtl -bdynamic -b64
Andres Freund writes:
> Maybe a daft question: Why do want any of the -l flags other than -lperl? With
> the patch configure spits out the following on my debian system:
> checking for CFLAGS to compile embedded Perl... -DDEBIAN
> checking for flags to link embedded Perl...
>
Hi,
On 2022-08-19 10:00:35 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > After analyzing the source code of ExtUtils::Embed's ldopts, I think we
> > can also do this by subtracting $Config{ldflags}, since
> > my $linkage = "$ccdlflags $ldflags @archives $ld_or_bs";
> > and we really just
Peter Eisentraut writes:
> After analyzing the source code of ExtUtils::Embed's ldopts, I think we
> can also do this by subtracting $Config{ldflags}, since
> my $linkage = "$ccdlflags $ldflags @archives $ld_or_bs";
> and we really just want the $ld_or_bs part. (@archives should be empty
> for
On 18.08.22 15:53, Tom Lane wrote:
Agreed on rejecting -mmacosx-version-min, but I wonder if we should
think about adopting a whitelist-instead-of-blacklist approach to
adopting stuff from perl_embed_ldflags. ISTR that in pltcl we already
use the approach of accepting only -L and -l, and
Peter Eisentraut writes:
> This is because the link command uses the option
> -mmacosx-version-min=11.3, which comes in from perl_embed_ldflags (perl
> -MExtUtils::Embed -e ldopts), but the compile commands don't use that
> option, which creates a situation that ld considers inconsistent.
> I
-mmacosx-version-min options from plperl build
---
config/perl.m4 | 2 +-
configure | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/config/perl.m4 b/config/perl.m4
index c823fc8cf0..65f338bda7 100644
--- a/config/perl.m4
+++ b/config/perl.m4
@@ -100,7 +100,7 @@ if test
33 matches
Mail list logo
