On 22.07.24 16:04, Peter Eisentraut wrote:
On 19.07.24 12:40, Aleksander Alekseev wrote:
It seems to me that the patch is not going to become any better and it
doesn't need any more attention from the reviewers. Thus I changed the
status of the CF entry to "Ready for Committer".
I'm happy to c
On 19.07.24 12:40, Aleksander Alekseev wrote:
It seems to me that the patch is not going to become any better and it
doesn't need any more attention from the reviewers. Thus I changed the
status of the CF entry to "Ready for Committer".
I'm happy to commit this patch.
I checked that for non-LT
On Sat, Jul 20, 2024 at 7:56 AM Andres Freund wrote:
> On 2024-07-19 15:36:29 -0400, Tom Lane wrote:
> > Andres Freund writes:
> > > On 2024-07-19 11:06:47 -0400, Tom Lane wrote:
> > >> 2. Do we really want to encourage people to build with -flto?
> >
> > > The only case I know where we do rely o
Hi,
> So ... there is quite a disconnect between what this patch actually
> does (i.e., probe to see if "-Wl,-export_dynamic" is accepted) and
> the title of this thread. [...]
The thread title is indeed somewhat misleading, I was initially
puzzled by it too. The actual idea, if I understood it
Hi,
On 2024-07-19 15:36:29 -0400, Tom Lane wrote:
> Andres Freund writes:
> > On 2024-07-19 11:06:47 -0400, Tom Lane wrote:
> >> 2. Do we really want to encourage people to build with -flto?
>
> > The only case I know where we do rely on compilation units providing some
> > level of boundaries i
Andres Freund writes:
> On 2024-07-19 11:06:47 -0400, Tom Lane wrote:
>> 2. Do we really want to encourage people to build with -flto?
> The only case I know where we do rely on compilation units providing some
> level of boundaries is on compilers where we don't know how to emit a compiler
> bar
Hi,
On 2024-07-19 11:06:47 -0400, Tom Lane wrote:
> 2. Do we really want to encourage people to build with -flto?
>
> I fear that #2 is actually a pretty serious concern. I think there
> are a lot of places where we've assumed semi-implicitly that
> compilation file boundaries are optimization b
Re: Tom Lane
> I fear that #2 is actually a pretty serious concern. I think there
> are a lot of places where we've assumed semi-implicitly that
> compilation file boundaries are optimization barriers, particularly
> around stuff like LWLocks and semaphores. I don't really want to
> spend time ch
Aleksander Alekseev writes:
> It seems to me that the patch is not going to become any better and it
> doesn't need any more attention from the reviewers. Thus I changed the
> status of the CF entry to "Ready for Committer".
So ... there is quite a disconnect between what this patch actually
does
Hi,
> So I tested both HEAD and v12 on current and current-5, both successful.
> That should cover current-1 and current-2, too. If you want me to test
> any other macOS versions inbetween, or any other PG versions, I can do that.
>
> I would really like to upstream those kind of patches and see t
Peter Eisentraut:
On 04.06.24 18:41, Tom Lane wrote:
Relevant to this: I wonder what we think the supported macOS versions
are, anyway. AFAICS, the buildfarm only covers current (Sonoma)
and current-1 (Ventura) major versions, and only the latest minor
versions in those OS branches.
For other
On 04.06.24 18:41, Tom Lane wrote:
Relevant to this: I wonder what we think the supported macOS versions
are, anyway. AFAICS, the buildfarm only covers current (Sonoma)
and current-1 (Ventura) major versions, and only the latest minor
versions in those OS branches.
For other OS lines I think w
Peter Eisentraut writes:
> With the native compiler tooling on macOS, it is not safe to assume
> anything, including that the man pages are accurate or that the
> documented options actually work correctly and don't break anything
> else. Unless we have actual testing on all the supported macO
Andres Freund:
Gah. Apples tendency to just break stuff that has worked across *nix-y
platforms for decades is pretty annoying. They could just have made
--export-dynamic an alias for --export_dynamic, but no, everyone needs a
special macos thingy in their build scripts.
Interesting enough my L
On 03.06.24 17:07, Wolfgang Walther wrote:
I don't mind addressing this in PG18, but I would hesitate with
backpatching. With macOS, it's always hard to figure out whether
these kinds of options work the same way going versions back.
All the versions for ld64 are in [1]. It seems this was int
Hi,
On 2024-06-03 17:07:22 +0200, Wolfgang Walther wrote:
> Peter Eisentraut:
> > It's probably worth clarifying that this option is needed on macOS only
> > if LTO is also enabled. For standard (non-LTO) builds, the
> > export-dynamic behavior is already the default on macOS (otherwise
> > nothi
Wolfgang Walther:
Peter:
I don't think we explicitly offer LTO builds as part of the make build
system, so anyone trying this would do it sort of self-service, by
passing additional options to configure or make. In which case they
might as well pass the -export_dynamic option along in the sam
Peter Eisentraut:
It's probably worth clarifying that this option is needed on macOS only
if LTO is also enabled. For standard (non-LTO) builds, the
export-dynamic behavior is already the default on macOS (otherwise
nothing in PostgreSQL would work).
Right, man page say this:
> Preserves al
On 03.06.24 16:22, Wolfgang Walther wrote:
Building with clang and -flto on macOS currently fails with errors
similar to [1]. This is because the --export-dynamic flag is called
-export_dynamic [2] instead and we have not been passing this variant to
the linker, so far.
It's probably worth cl
Building with clang and -flto on macOS currently fails with errors
similar to [1]. This is because the --export-dynamic flag is called
-export_dynamic [2] instead and we have not been passing this variant to
the linker, so far.
Attached patch fixes that for configure/make.
CC: Tom, who hit th
20 matches
Mail list logo
