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 <and...@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
