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 <andrew@dunslane.net> 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 being prefixed with _. I noticed that the
> > underscore prefix e.g. changes the behaviour of gcc's "collect2" on AIX, which
> > is responsible for exporting symbols etc.
> >
> >
> >> Hmph. Hard to see how that isn't a linker bug.
> > Agreed, given that this is only happening with plperl, and not with any of the
> > other extensions...
> >
> >
> >> As a stopgap to get the farm green again, I propose adding something like
> >>
> >> ifeq ($(PORTNAME), cygwin)
> >> SHLIB_LINK += -Wl,--export-all-symbols
> >> endif
> >>
> >> to plperl's makefile.
> > :(
> >
>
> It doesn't make me very happy either, but nobody seems to have a better
> idea.
The plpython issue I was investigating in
https://postgr.es/m/20220928022724.erzuk5v4ai4b53do%40awork3.anarazel.de
feels eerily similar to the issue here.
I wonder if it's the same problem - __attribute__((visibility("default")))
works to export - unless another symbol uses __declspec (dllexport). In the
referenced thread that was PyInit_plpy(), here it could be some perl generated
one.
Does this issue resolved if you add
#define PGDLLEXPORT __declspec (dllexport)
to cygwin.h? Without the -Wl,--export-all-symbols of course.
Greetings,
Andres Freund
