Good day!
I'm encountering a build issue with postgresql 17, I wonder if this was an
intentional consequence of this commit:
https://github.com/postgres/postgres/commit/b6c7cfac88c47a9194d76f3d074129da3c46545a
Or if this was unintentional. Or is there any way to compile pgcommon with
the correct
Hi,
Looks like I forgot to update the thread to note that I finally committed the
remaining warning fixes. I had already fixed a bunch of others in upstream
meson.
commit a3da95deee38ee067b0bead639c830eacbe894d5
Author: Andres Freund
Date: 2024-03-13 01:40:53 -0700
meson: macos: Avoid war
Hi,
On 2023-11-30 21:24:21 -0500, Tom Lane wrote:
> Andres Freund writes:
> > On 2023-11-28 10:48:04 -0500, Robert Haas wrote:
> >> What a stupid, annoying decision on Apple's part. It seems like
> >> -Wl,-undefined,error is the default behavior, so they could have just
> >> ignored that flag if
Andres Freund writes:
> On 2023-11-28 10:48:04 -0500, Robert Haas wrote:
>> What a stupid, annoying decision on Apple's part. It seems like
>> -Wl,-undefined,error is the default behavior, so they could have just
>> ignored that flag if present, but instead they complain about being
>> asked to do
Hi,
On 2023-11-28 10:48:04 -0500, Robert Haas wrote:
> The second conclusion that I draw is that there's something in meson
> itself which is adding -Wl,-undefined,error when building binaries.
Right.
> What a stupid, annoying decision on Apple's part. It seems like
> -Wl,-undefined,error is th
On Tue, Nov 21, 2023 at 9:59 AM Peter Eisentraut wrote:
> Btw., I'm also seeing warnings like this. I'm using homebrew. Here is
> a sample:
>
> [145/147] Linking target src/test/modules/test_shm_mq/test_shm_mq.dylib
> -macosx_version_min has been renamed to -macos_version_min
> ld: warning: -und
Hi,
> > On Mon, Nov 20, 2023 at 11:37 PM Andres Freund wrote:
> >> WRT Robert seeing those warnings and Tom not: There's something odd going
> >> on. I couldn't immediately reproduce it. Then I realized it reproduces
> >> against
> >> a homebrew install but not a macports one.
> >>
> >> Robert,
On 21.11.23 14:35, Robert Haas wrote:
On Mon, Nov 20, 2023 at 11:37 PM Andres Freund wrote:
WRT Robert seeing those warnings and Tom not: There's something odd going
on. I couldn't immediately reproduce it. Then I realized it reproduces against
a homebrew install but not a macports one.
Robert
On Mon, Nov 20, 2023 at 11:37 PM Andres Freund wrote:
> WRT Robert seeing those warnings and Tom not: There's something odd going
> on. I couldn't immediately reproduce it. Then I realized it reproduces against
> a homebrew install but not a macports one.
>
> Robert, which are you using?
macports
Hi,
On 2023-11-20 16:20:20 -0500, Tom Lane wrote:
> I'm generally still using autoconf, I only run meson builds when
> somebody complains about them ;-). But yeah, I see lots of
> "ld: warning: -undefined error is deprecated" when I do that.
> This seems to have been installed by Andres' 9a95a510
I wrote:
> The autoconf side seems to just be letting this option default.
> I'm not sure what the default choice is, but evidently it's not
> "-undefined error"? Or were they stupid enough to not allow you
> to explicitly select the default behavior?
Seems we are not the only project having trou
Robert Haas writes:
> On Mon, Nov 20, 2023 at 3:53 PM Tom Lane wrote:
>> 13.6.2? longfin's host is on 13.6.1, and the only thing Software
>> Update is showing me is an option to upgrade to Sonoma. But anyway...
> Uh, I guess Apple made a special version just for me? That's
> definitely what it
On Mon, Nov 20, 2023 at 3:53 PM Tom Lane wrote:
> 13.6.2? longfin's host is on 13.6.1, and the only thing Software
> Update is showing me is an option to upgrade to Sonoma. But anyway...
Uh, I guess Apple made a special version just for me? That's
definitely what it says.
> > [2264/2287] Linki
Robert Haas writes:
> Is there still outstanding work on this thread? Because I'm just now
> using a new MacBook (M2, Ventura 13.6.2) and I'm getting a lot of this
> kind of thing in a meson build:
13.6.2? longfin's host is on 13.6.1, and the only thing Software
Update is showing me is an option
Hi,
On 2023-11-20 14:46:13 -0500, Robert Haas wrote:
> On Mon, Nov 20, 2023 at 2:35 PM Andres Freund wrote:
> > > Is there still outstanding work on this thread? Because I'm just now
> > > using a new MacBook (M2, Ventura 13.6.2) and I'm getting a lot of this
> > > kind of thing in a meson build:
On Mon, Nov 20, 2023 at 2:35 PM Andres Freund wrote:
> > Is there still outstanding work on this thread? Because I'm just now
> > using a new MacBook (M2, Ventura 13.6.2) and I'm getting a lot of this
> > kind of thing in a meson build:
>
> Ventura? In that case I assume you installed newer develo
Hi,
On 2023-11-20 14:14:00 -0500, Robert Haas wrote:
> On Sat, Oct 7, 2023 at 12:09 PM Tom Lane wrote:
> > Done that way.
>
> Is there still outstanding work on this thread? Because I'm just now
> using a new MacBook (M2, Ventura 13.6.2) and I'm getting a lot of this
> kind of thing in a meson b
On Sat, Oct 7, 2023 at 12:09 PM Tom Lane wrote:
> Done that way.
Is there still outstanding work on this thread? Because I'm just now
using a new MacBook (M2, Ventura 13.6.2) and I'm getting a lot of this
kind of thing in a meson build:
[2264/2287] Linking target src/interfaces/ecpg/test/sql/par
Andres Freund writes:
> On 2023-10-05 13:37:38 -0400, Tom Lane wrote:
>> Hm. IIUC that would result in an error if someone did try to
>> put some c_args into default_bin_args, and I didn't think it would
>> be appropriate for this code to fail in such a case. Still, I see
>> there are a bunch of
Hi,
On 2023-10-05 13:37:38 -0400, Tom Lane wrote:
> Andres Freund writes:
> > I think you can just pass c_args directly to executable() here, I think
> > adding
> > c_args to default_bin_args would be a bad idea.
>
> Hm. IIUC that would result in an error if someone did try to
> put some c_arg
Andres Freund writes:
> I think you can just pass c_args directly to executable() here, I think adding
> c_args to default_bin_args would be a bad idea.
Hm. IIUC that would result in an error if someone did try to
put some c_args into default_bin_args, and I didn't think it would
be appropriate
Hi,
On 2023-10-05 13:17:25 -0400, Tom Lane wrote:
> I wrote:
> > So I experimented with fixing things so that the versions of these
> > functions exported by libpq have physically different names from those
> > that you'd get from linking to libpgcommon.a or libpgcommon_srv.a.
> > Then, there's ce
I wrote:
> So I experimented with fixing things so that the versions of these
> functions exported by libpq have physically different names from those
> that you'd get from linking to libpgcommon.a or libpgcommon_srv.a.
> Then, there's certainty about which one a given usage will link to,
> based o
I wrote:
> Assuming that this problem is restricted to initdb, which I think
> is true, probably the best fix is to cause the initdb link *only*
> to link libpgcommon before libpq. Every other non-backend program
> is interested in libpq's encoding IDs if it cares at all.
The more I thought about
I wrote:
> Andres Freund writes:
>> On 2023-09-29 12:14:40 -0400, Tom Lane wrote:
>>> Therefore, I think the prudent thing to do in the back branches is use the
>>> patch I posted before, to suppress the duplicate -l switches only on macOS.
>>> In HEAD, I propose we simplify life by doing it every
Hi,
On 2023-09-29 11:11:49 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2023-09-28 22:53:09 -0400, Tom Lane wrote:
> >> (Perhaps we should apply the above to HEAD alongside the meson.build fix,
> >> to
> >> get more test coverage?)
>
> > The macos animals BF seem to run Ventura, so I t
Hi,
On 2023-09-30 13:28:01 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2023-09-29 12:14:40 -0400, Tom Lane wrote:
> >> Looking closer, it's only since v16 that we have export list support
> >> on all officially-supported platforms.
>
> > Oh, right, before that Solaris didn't support it
Andres Freund writes:
> On 2023-09-29 12:14:40 -0400, Tom Lane wrote:
>> Looking closer, it's only since v16 that we have export list support
>> on all officially-supported platforms.
> Oh, right, before that Solaris didn't support it. I guess we could backpatch
> that commit, it's simple enough,
Hi,
On 2023-09-29 12:14:40 -0400, Tom Lane wrote:
> I wrote:
> > Andres Freund writes:
> >> On 2023-09-28 16:46:08 -0400, Tom Lane wrote:
> >>> Well, it's only important on platforms where we can't restrict
> >>> libpq.so from exporting all symbols. I don't know how close we are
> >>> to decidin
I wrote:
> Andres Freund writes:
>> On 2023-09-28 16:46:08 -0400, Tom Lane wrote:
>>> Well, it's only important on platforms where we can't restrict
>>> libpq.so from exporting all symbols. I don't know how close we are
>>> to deciding that such cases are no longer interesting to worry about.
>>>
On Thu Sep 28, 2023 at 5:22 PM CDT, Andres Freund wrote:
Hi,
On 2023-09-28 16:46:08 -0400, Tom Lane wrote:
> There's still one duplicate warning
> from the backend link:
>
> ld: warning: ignoring duplicate libraries: '-lpam'
>
> I'm a bit baffled why that's showing up; there's no obvious
> do
Andres Freund writes:
> On 2023-09-28 22:53:09 -0400, Tom Lane wrote:
>> (Perhaps we should apply the above to HEAD alongside the meson.build fix, to
>> get more test coverage?)
> The macos animals BF seem to run Ventura, so I think it'd not really provide
> additional coverage that CI and your m
Hi,
On 2023-09-28 22:53:09 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2023-09-28 19:20:27 -0700, Andres Freund wrote:
> >> Thus the easiest fix looks to be to use this:
> >> - export_fmt = '-exported_symbols_list=@0@'
> >> + export_fmt = '-Wl,-exported_symbols_list,@0@'
> >> I don't
Andres Freund writes:
> On 2023-09-28 19:20:27 -0700, Andres Freund wrote:
>> Thus the easiest fix looks to be to use this:
>> - export_fmt = '-exported_symbols_list=@0@'
>> + export_fmt = '-Wl,-exported_symbols_list,@0@'
>> I don't have anything older than Ventura to check though.
I don't have
Hi,
On 2023-09-28 19:20:27 -0700, Andres Freund wrote:
> Thus the easiest fix looks to be to use this:
>
> diff --git a/meson.build b/meson.build
> index 5422885b0a2..16a2b0f801e 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -224,7 +224,7 @@ elif host_system == 'darwin'
>library_path_va
Hi,
On 2023-09-28 19:17:37 -0400, Tom Lane wrote:
> I wrote:
> > Andres Freund writes:
> >> I think right now it doesn't work as-is on sonoma, because apple decided to
> >> change the option syntax, which is what causes the -e warning below, so the
> >> relevant option is just ignored.
>
> > Hmm
I wrote:
> Andres Freund writes:
>> I think right now it doesn't work as-is on sonoma, because apple decided to
>> change the option syntax, which is what causes the -e warning below, so the
>> relevant option is just ignored.
> Hmm, we'd better fix that then. Or is it their bug? It looks to me
Andres Freund writes:
> On 2023-09-28 16:46:08 -0400, Tom Lane wrote:
>> Well, it's only important on platforms where we can't restrict
>> libpq.so from exporting all symbols. I don't know how close we are
>> to deciding that such cases are no longer interesting to worry about.
>> Makefile.shlib
Hi,
On 2023-09-28 16:46:08 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2023-09-27 16:52:44 -0400, Tom Lane wrote:
> >> I think it doesn't, as long as all the relevant build targets
> >> write their dependencies with "frontend_code" before "libpq".
>
> > Hm, that's not great. I don't th
Andres Freund writes:
> On 2023-09-27 16:52:44 -0400, Tom Lane wrote:
>> I think it doesn't, as long as all the relevant build targets
>> write their dependencies with "frontend_code" before "libpq".
> Hm, that's not great. I don't think that should be required. I'll try to take
> a look at why t
Hi,
On 2023-09-27 16:52:44 -0400, Tom Lane wrote:
> I wrote:
> > I've not yet looked at the meson build infrastructure to
> > see if it needs a corresponding change.
>
> I think it doesn't, as long as all the relevant build targets
> write their dependencies with "frontend_code" before "libpq".
I wrote:
> I've not yet looked at the meson build infrastructure to
> see if it needs a corresponding change.
I think it doesn't, as long as all the relevant build targets
write their dependencies with "frontend_code" before "libpq".
(The need for this is, of course, documented nowhere. The state
I wrote:
> Since updating to Xcode 15.0, my macOS machines have been
> spitting a bunch of linker-generated warnings. ...
> some program links complain
> ld: warning: ignoring duplicate libraries: '-lpgcommon', '-lpgport'
I found that this is being caused by the libpq_pgport hack in
Makefile.glob
I wrote:
> Since updating to Xcode 15.0, my macOS machines have been
> spitting a bunch of linker-generated warnings. There
> seems to be one instance of
> ld: warning: -multiply_defined is obsolete
> for each loadable module we link ...
I poked into this a little more. We started using "-multip
Since updating to Xcode 15.0, my macOS machines have been
spitting a bunch of linker-generated warnings. There
seems to be one instance of
ld: warning: -multiply_defined is obsolete
for each loadable module we link, and some program links complain
ld: warning: ignoring duplicate libraries: '-lp
45 matches
Mail list logo