Thread: [PATCH] Add an ldflags_sl meson build option
Currently there doesn't seem to be a way to pass shared library-specific flags via a meson build option.
This patch allows the existing ldflags_sl to be set via a build option.
Patch created against the 17.4 release.
Attachment
On 16.06.25 06:10, Matt Smith (matts3) wrote: > Currently there doesn't seem to be a way to pass shared library-specific > flags via a meson build option. > > This patch allows the existing ldflags_sl to be set via a build option. What uses do you have in mind for this?
I have a Bazel toolchain that sets different linker flags for exe/shared lib.
I wanted to build postgresql shared libs with meson using the same toolchain flags that I build all my other 3rd party deps in Bazel.
Currently for postgresql builds, we set LDFLAGS to the Bazel toolchain executable flags which means that any postgresql shared_library() gets the exe flags.
I noticed ldflags_sl was already setup to pass through shared_library flags, but I couldn't find a way to set it via meson build options.
From: Peter Eisentraut <peter@eisentraut.org>
Sent: Monday, June 16, 2025 9:32 PM
To: Matt Smith (matts3) <matts3@cisco.com>; pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Subject: Re: [PATCH] Add an ldflags_sl meson build option
Sent: Monday, June 16, 2025 9:32 PM
To: Matt Smith (matts3) <matts3@cisco.com>; pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Subject: Re: [PATCH] Add an ldflags_sl meson build option
On 16.06.25 06:10, Matt Smith (matts3) wrote:
> Currently there doesn't seem to be a way to pass shared library-specific
> flags via a meson build option.
>
> This patch allows the existing ldflags_sl to be set via a build option.
What uses do you have in mind for this?
> Currently there doesn't seem to be a way to pass shared library-specific
> flags via a meson build option.
>
> This patch allows the existing ldflags_sl to be set via a build option.
What uses do you have in mind for this?
Yes I understand what you're saying. I know Meson tries to set some of these flags. But I want the source of truth for my flags for each target type to be outside Meson. Which Meson is not designed to do.
When you're building many 3rd party deps all with different build systems and all trying to tweak flags here and there, it introduces much better consistency to specify "all targets of a certain type use this flag set". Otherwise you end up having to write logic to filter flags per build system/package. And yes I realize we live in an imperfect world and packages such as postgres will in fact need to set project-specific flags, but this should be an exception.
I have raised an issue on Meson itself: https://github.com/mesonbuild/meson/issues/14621
Cmake has functionality whereby you can specify linker flags per target type and it will set them accordingly. Meson doesn't have this type of feature and instead sets base flags itself across all targets.
So it would be helpful if postgresql could "drill a hole" as you say to shared_library() flags because then at least those flags can be overrriden externally just for those targets.
If you don't mind me asking - I assume ldflags_sl exists as a way for postgres internally to be able to set flags across all shared libs?
From: Peter Eisentraut <peter@eisentraut.org>
Sent: Wednesday, June 18, 2025 3:34 PM
To: Matt Smith (matts3) <matts3@cisco.com>; pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Subject: Re: [PATCH] Add an ldflags_sl meson build option
Sent: Wednesday, June 18, 2025 3:34 PM
To: Matt Smith (matts3) <matts3@cisco.com>; pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Subject: Re: [PATCH] Add an ldflags_sl meson build option
On 18.06.25 03:11, Matt Smith (matts3) wrote:
> An example of a shared library-specific flag is -shared on linux or -
> dynamiclib on darwin.
But those options are already added by the build system itself.
LDFLAGS_SL would be if you wanted to pass some additional custom linker
flag just for shared libraries.
The reason I'm skeptical is that Meson generally wants to handle that
sort of thing with higher-level build options, not by passing flags
through directly. So I wouldn't want to drill additional holes into
that system without a clear use case.
> An example of a shared library-specific flag is -shared on linux or -
> dynamiclib on darwin.
But those options are already added by the build system itself.
LDFLAGS_SL would be if you wanted to pass some additional custom linker
flag just for shared libraries.
The reason I'm skeptical is that Meson generally wants to handle that
sort of thing with higher-level build options, not by passing flags
through directly. So I wouldn't want to drill additional holes into
that system without a clear use case.
On 18.06.25 08:40, Matt Smith (matts3) wrote: > Yes I understand what you're saying. I know Meson tries to set some of > these flags. But I want the source of truth for my flags for each target > type to be outside Meson. Which Meson is not designed to do. > > When you're building many 3^rd party deps all with different build > systems and all trying to tweak flags here and there, it introduces much > better consistency to specify "all targets of a certain type use this > flag set". Otherwise you end up having to write logic to filter flags > per build system/package. And yes I realize we live in an imperfect > world and packages such as postgres will in fact need to set project- > specific flags, but this should be an exception. > > I have raised an issue on Meson itself: https://github.com/mesonbuild/ > meson/issues/14621 <https://github.com/mesonbuild/meson/issues/14621> > > Cmake has functionality whereby you can specify linker flags per target > type and it will set them accordingly. Meson doesn't have this type of > feature and instead sets base flags itself across all targets. Yeah, I see myself agreeing with the answers on that Meson issue. I think this is just not how the tool was meant to be used. > So it would be helpful if postgresql could "drill a hole" as you say to > shared_library() flags because then at least those flags can be > overrriden externally just for those targets. > > If you don't mind me asking - I assume ldflags_sl exists as a way for > postgres internally to be able to set flags across all shared libs? I think this is all legacy from makefiles. With makefiles there isn't a clear boundary between what variables are internal and external. And at some point someone thought that it would be useful to document the LDFLAGS_SL variable as external. But I don't know why anyone would use it. I can make up some ideas retrospectively, perhaps someone wanted to play around with -fvisibility or -fPIE or stuff like that. But even then I would wonder whether it has the right granularity, since you might need different flags for shared modules versus shared libraries. That's why I asked you if you had a specific use case for an option to pass. And then we could have thought about a way to expose that option in a dedicated way perhaps. But I think this idea that you want to control all the options yourself is just not the way this is meant to be working.