Hi,
On 2022-10-15 22:50:07 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I guess we should report the CFLAGS_SL_MODULE etc via pg_config?
>
> Dunno ... where do you stop? I'm not really convinced that extensions
> that don't want to use PGXS have any claim on our buildsystem to provide
>
Andres Freund writes:
> I guess we should report the CFLAGS_SL_MODULE etc via pg_config?
Dunno ... where do you stop? I'm not really convinced that extensions
that don't want to use PGXS have any claim on our buildsystem to provide
platform-specific configuration details for them.
Hi,
On 2022-09-01 14:19:35 -0700, Andres Freund wrote:
> Here's an updated patch for this (also shared recently on another thread).
I've since then committed this.
I was reminded of this when thinking about
https://postgr.es/m/1595488.1665869988%40sss.pgh.pa.us
Thinking about this made me
Hi,
On 2022-07-27 14:02:28 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2022-07-18 00:05:16 -0700, Andres Freund wrote:
> >> Given that that's just about all compilers we support using configure,
> >> perhaps
> >> we should just move that out of the compiler specific section? Doesn't
Andres Freund writes:
> On 2022-07-18 00:05:16 -0700, Andres Freund wrote:
>> Given that that's just about all compilers we support using configure,
>> perhaps
>> we should just move that out of the compiler specific section? Doesn't look
>> like there's much precedent for that so far...
>
Hi,
On 2022-07-18 00:05:16 -0700, Andres Freund wrote:
> It looks like we might be missing out on benefiting from this on more
> platforms - the test right now is in the gcc specific section of configure.ac,
> but it looks like at least Intel's, sun's and AIX's compilers might all
> support
Hi,
On 2022-07-17 14:54:48 -0400, Tom Lane wrote:
> Beyond that, I think this is committable. We're not likely to learn much
> more about any potential issues except by exposing it to the buildfarm
> and developer usage.
Leaving egg on my face aside, seems to work well so far.
It looks like we
Andres Freund writes:
> That's also the reason -fvisibility=hidden isn't added to libpq and the ecpg
> libs - their symbol visility is done via exports.txt. Depending on the
> platform that'd not work if symbols were already hidden via
> -fvisibility=hidden (unless explicitly exported via
Hi,
Thanks for the quick review.
On 2022-07-17 14:54:48 -0400, Tom Lane wrote:
> Andres Freund writes:
> > Is there any reason an extension module would need to directly link against
> > pgport/pgcommon? I don't think so, right?
>
> Shouldn't --- we want it to use the backend's own copy.
Andres Freund writes:
> On 2022-03-24 16:13:31 +0100, Peter Eisentraut wrote:
>> The easiest solution would be to change worker_spi's Makefile to use
>> MODULE_big.
> If it were just worker_spi that might be tenable, but there's other extension
> modules - even if they don't fail to fail right
Hi,
On 2022-03-24 16:13:31 +0100, Peter Eisentraut wrote:
> On 11.01.22 03:53, Andres Freund wrote:
> > Ugh. In the case of worker_spi it's because -fvisibility=hidden isn't
> > applied
> > to worker_spi.c at all. Which in turn is because Makefile.shlib isn't used
> > at
> > all for MODULES=
Hi,
On 2022-01-11 15:54:19 -0500, Tom Lane wrote:
> I still don't understand what are the conditions for MSVC to complain.
> The rule is evidently not that every extern must agree with the function
> definition, because for example you added
>
> +extern PGDLLEXPORT void _PG_init(void);
>
> in
On 11.01.22 03:53, Andres Freund wrote:
Ugh. In the case of worker_spi it's because -fvisibility=hidden isn't applied
to worker_spi.c at all. Which in turn is because Makefile.shlib isn't used at
all for MODULES= style modules just for MODULE_big= ones :(.
Once that's "fixed" it fails as
Andres Freund writes:
> What is bugging me is that I am fairly sure that my local compilers at some
> point complained about such mismatches on linux as well. But I can't reproduce
> that right now :/
> Now I wonder if I just saw it when cross compiling locally...
I still don't understand what
Hi,
On 2022-01-10 23:44:06 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2022-01-10 21:11:07 -0600, Justin Pryzby wrote:
> >> Without the patch, it fails under windows like:
>
> > Ah, yea. It's about matching the declarations in ltree.h with the
> > PG_FUNCTION_INFO_V1() one.
>
> >
Andres Freund writes:
> On 2022-01-10 21:11:07 -0600, Justin Pryzby wrote:
>> Without the patch, it fails under windows like:
> Ah, yea. It's about matching the declarations in ltree.h with the
> PG_FUNCTION_INFO_V1() one.
> What is bugging me is that I am fairly sure that my local compilers at
Hi,
On 2022-01-10 21:11:07 -0600, Justin Pryzby wrote:
> On Mon, Jan 10, 2022 at 07:01:36PM -0500, Tom Lane wrote:
> > Andres Freund writes:
> > > [ v2-0001-Use-hidden-visibility-for-shared-libraries-where-.patch ]
> >
> > This seems like a good idea, but it's failing to apply right now,
> >
On Mon, Jan 10, 2022 at 07:01:36PM -0500, Tom Lane wrote:
> Andres Freund writes:
> > [ v2-0001-Use-hidden-visibility-for-shared-libraries-where-.patch ]
>
> This seems like a good idea, but it's failing to apply right now,
> mainly because of some cleanup I did in e04a8059a. As far as I can
>
Hi,
On 2022-01-10 19:01:36 -0500, Tom Lane wrote:
> Andres Freund writes:
> > [ v2-0001-Use-hidden-visibility-for-shared-libraries-where-.patch ]
>
> This seems like a good idea, but it's failing to apply right now,
> mainly because of some cleanup I did in e04a8059a. As far as I can
> tell
Andres Freund writes:
> [ v2-0001-Use-hidden-visibility-for-shared-libraries-where-.patch ]
This seems like a good idea, but it's failing to apply right now,
mainly because of some cleanup I did in e04a8059a. As far as I can
tell given the now-clarified meanings of PGDLLIMPORT/PGDLLEXPORT,
this
Hi,
On 2021-11-01 05:55:40 +0100, Laurenz Albe wrote:
> I see that at least clang and gcc support this flag.
Yes - and have for a long time. 2004 or so.
> Could the reduced number of exported functions be a problem, if someone
> relies on some function being exported? It may not be worth
On Sun, 2021-10-31 at 19:03 -0700, Andres Freund wrote:
> Currently postgres builds extension shared libraries (i.e. pretty much
> everything but libpq) with global visibilty. I.e. symbols that are not
> static will be visible from outside the shared library.
>
> On the one platform where that
Hi,
Currently postgres builds extension shared libraries (i.e. pretty much
everything but libpq) with global visibilty. I.e. symbols that are not
static will be visible from outside the shared library.
On the one platform where that behaviour is not available, namely
windows, we emulate it by
23 matches
Mail list logo
