It would appear weak symbol linking is not handled properly without
'isysroot' parameter passed to linker.
Fixes:
Undefined symbols for architecture x86_64:
"___darwin_check_fd_set_overflow", referenced from:
_ClientAuthentication in auth.o
_pgstat_init in pgstat.o
_ServerLoop
On Thu, Nov 19, 2020 at 5:40 PM Tom Lane wrote:
>
> James Hilliard writes:
> > It would appear weak symbol linking is not handled properly without
> > 'isysroot' parameter passed to linker.
>
> Nobody else has reported this problem, so maybe you should tell u
Xcode sysroot, so I think this patch is
still correct
in that case as it forces the use of the Xcode sysroot for linking which should
be what we want as we want it to match sysroot passed to the compiler.
On Thu, Nov 19, 2020 at 5:45 PM James Hilliard
wrote:
>
> On Thu, Nov 19, 2020 at 5
On Thu, Nov 19, 2020 at 6:04 PM Tom Lane wrote:
>
> James Hilliard writes:
> > Hmm, maybe it's a more recent issue then, I took the version number
> > from the qt patch assuming it was the same issue, I hit it trying to build
> > master on Xcode 12.2 Build versi
On Thu, Nov 19, 2020 at 7:20 PM Tom Lane wrote:
>
> James Hilliard writes:
> > On Thu, Nov 19, 2020 at 6:04 PM Tom Lane wrote:
> >> The cases we've got in the buildfarm are Xcode 12.0 on Catalina (10.15.7)
> >> and Xcode 12.2 on Big Sur (11.0.1 ...
On Thu, Nov 19, 2020 at 7:48 PM Tom Lane wrote:
>
> I wrote:
> > However ... it then occurred to me to blow away my ccache and accache,
> > and after rebuilding from scratch, everything's fine. So, are you
> > using ccache?
>
> Oh, scratch that, I fat-fingered the experiment somehow. The issue
>
On Thu, Nov 19, 2020 at 9:02 PM Tom Lane wrote:
>
> James Hilliard writes:
> > On Thu, Nov 19, 2020 at 7:48 PM Tom Lane wrote:
> >> Oh, scratch that, I fat-fingered the experiment somehow. The issue
> >> is still there. Still, I'm hesitant to apply the fix y
OSX implements sysv shmem support via a mach wrapper, however the mach
sysv shmem wrapper has some severe restrictions that prevent us from
allocating enough memory segments in some cases.
These limits appear to be due to the way the wrapper itself is
implemented and not mach.
For example when ru
On Mon, Jan 18, 2021 at 5:29 PM Tom Lane wrote:
>
> James Hilliard writes:
> > OSX implements sysv shmem support via a mach wrapper, however the mach
> > sysv shmem wrapper has some severe restrictions that prevent us from
> > allocating enough memory segments in some cas
On Mon, Jan 18, 2021 at 5:29 PM Tom Lane wrote:
>
> James Hilliard writes:
> > OSX implements sysv shmem support via a mach wrapper, however the mach
> > sysv shmem wrapper has some severe restrictions that prevent us from
> > allocating enough memory segments in some cas
Fixes:
gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement
-Werror=vla -Wendif-labels -Wmissing-format-attribute -Wformat-security
-fno-strict-aliasing -fwrapv -Wno-unused-command-line-argument -O2
-I../../../../src/include -isysroot
/Applications/Xcode.app/Contents/De
On Mon, Jan 18, 2021 at 11:12 PM Tom Lane wrote:
>
> James Hilliard writes:
> > from my understanding due to mach semantics a number of the sanity checks
> > we are doing for sysv shmem are probably unnecessary when using mach
> > API's due to the mach port
On Thu, Jan 14, 2021 at 6:45 PM Tom Lane wrote:
>
> Sergey Shinderuk writes:
> > On 15.01.2021 01:13, Tom Lane wrote:
> >> Also, after re-reading [1] I am not at all excited about trying to
> >> remove the -isysroot switches from our *FLAGS. What I propose to do
> >> is keep that, but improve ou
On Tue, Jan 19, 2021 at 8:27 AM Tom Lane wrote:
>
> James Hilliard writes:
> > Fixes:
> > gcc -Wall -Wmissing-prototypes -Wpointer-arith
> > -Wdeclaration-after-statement -Werror=vla -Wendif-labels
> > -Wmissing-format-attribute -Wformat-security -fno-strict-ali
On Tue, Jan 19, 2021 at 8:57 AM Tom Lane wrote:
>
> James Hilliard writes:
> > On Tue, Jan 19, 2021 at 8:27 AM Tom Lane wrote:
> >> We already dealt with that by not selecting an SDK newer than the
> >> underlying OS (see 4823621db).
>
> > Tried that, d
Fixes:
gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement
-Werror=vla -Wendif-labels -Wmissing-format-attribute -Wformat-security
-fno-strict-aliasing -fwrapv -Wno-unused-command-line-argument -O2
-I../../../../src/include -isysroot
/Applications/Xcode.app/Contents/De
On Tue, Jan 19, 2021 at 10:17 AM Tom Lane wrote:
>
> James Hilliard writes:
> > On Tue, Jan 19, 2021 at 8:57 AM Tom Lane wrote:
> >> It worked for me and for Sergey, so we need to figure out what's different
> >> about your setup. What do you get from &quo
On Tue, Jan 19, 2021 at 10:29 AM Tom Lane wrote:
>
> James Hilliard writes:
> > Fixes:
> > fd.c:3661:10: warning: 'pwritev' is only available on macOS 11.0 or newer
> > [-Wunguarded-availability-new]
>
> It's still missing preadv, and it stil
On Tue, Jan 19, 2021 at 1:54 PM Tom Lane wrote:
>
> James Hilliard writes:
> > On Tue, Jan 19, 2021 at 10:17 AM Tom Lane wrote:
> >> Ah, got it. So "xcrun --show-sdk-path" tells us the right thing (that
> >> is, it *does* give us a symlink to a 10.15 SD
On Tue, Jan 19, 2021 at 3:47 PM James Hilliard
wrote:
>
> On Tue, Jan 19, 2021 at 1:54 PM Tom Lane wrote:
> >
> > James Hilliard writes:
> > > On Tue, Jan 19, 2021 at 10:17 AM Tom Lane wrote:
> > >> Ah, got it. So "xcrun --show-sdk-path" t
On Tue, Jan 19, 2021 at 6:37 PM Tom Lane wrote:
>
> James Hilliard writes:
> > Actually, this looks path looks wrong in general, the value for
> > "xcrun --sdk macosx --show-sdk-path" should take precedence over
> > "xcrun --show-sdk-path" as the latt
On Wed, Jan 20, 2021 at 4:07 PM Tom Lane wrote:
>
> James Hilliard writes:
> > On Tue, Jan 19, 2021 at 6:37 PM Tom Lane wrote:
> >> I've found no direct means to control the
> >> SDK path at all, but so far it appears that "xcrun --show-sdk-path&
On Thu, Jan 21, 2021 at 11:38 AM Tom Lane wrote:
>
> James Hilliard writes:
> > On Wed, Jan 20, 2021 at 4:07 PM Tom Lane wrote:
> >> I'm not sure that the case of not having the "command line tools"
> >> installed is interesting for our purposes.
Fixes:
gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement
-Werror=vla -Wendif-labels -Wmissing-format-attribute -Wformat-security
-fno-strict-aliasing -fwrapv -Wno-unused-command-line-argument -O2
-I../../../../src/include -isysroot
/Applications/Xcode.app/Contents/De
On Thu, Jan 21, 2021 at 11:38 AM Tom Lane wrote:
>
> James Hilliard writes:
> > On Wed, Jan 20, 2021 at 4:07 PM Tom Lane wrote:
> >> I'm not sure that the case of not having the "command line tools"
> >> installed is interesting for our purposes.
On Sat, Jan 23, 2021 at 1:27 AM Sergey Shinderuk
wrote:
>
> On 23.01.2021 08:02, Sergey Shinderuk wrote:
> >> On the whole it looks like we should recommend installing the CLT
> >> and not bothering with Xcode, which is about 10X the size:
> >>
> >> $ du -hs /Library/Developer/CommandLineTools
> >
On Fri, Jan 22, 2021 at 12:32 PM James Hilliard
wrote:
>
> Fixes:
> gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement
> -Werror=vla -Wendif-labels -Wmissing-format-attribute -Wformat-security
> -fno-strict-aliasing -fwrapv -Wno-unused-command-line-arg
On Fri, Jan 22, 2021 at 1:53 PM James Hilliard
wrote:
>
> On Thu, Jan 21, 2021 at 11:38 AM Tom Lane wrote:
> >
> > James Hilliard writes:
> > > On Wed, Jan 20, 2021 at 4:07 PM Tom Lane wrote:
> > >> I'm not sure that the case of not having
Should it work if I just attach it to the thread like this?
On Mon, Mar 29, 2021 at 7:52 AM David Steele wrote:
>
> Hi James,
>
> On 1/31/21 1:59 AM, James Hilliard wrote:
> > On Fri, Jan 22, 2021 at 12:32 PM James Hilliard
> > wrote:
> >>
> >>
This fixes an issue where preadv and pwritev detection does not
properly respect the OSX deployment target version symbol
availability.
James
v3-0001-Fix-detection-of-preadv-pwritev-support-for-OSX.patch
Description: Binary data
On Mon, Mar 29, 2021 at 4:10 PM Thomas Munro wrote:
>
> On Tue, Mar 30, 2021 at 6:37 AM James Hilliard
> wrote:
> > Should it work if I just attach it to the thread like this?
>
> Yes. It automatically tries patches that are attached to threads that
> are registered on c
On Mon, Mar 29, 2021 at 11:58 PM Tom Lane wrote:
>
> Thomas Munro writes:
> > I'll move it when committing. I'll let this patch sit for another day
> > to see if any other objections show up.
>
> FWIW, I remain fairly strongly against this, precisely because of the
> point that it requires us to
On Tue, Mar 30, 2021 at 6:43 PM Thomas Munro wrote:
>
> On Tue, Mar 30, 2021 at 7:39 PM James Hilliard
> wrote:
> > On Mon, Mar 29, 2021 at 11:58 PM Tom Lane wrote:
> > > We haven't claimed in the past to support MACOSX_DEPLOYMENT_TARGET,
> > > and I
On Tue, Mar 30, 2021 at 7:51 PM Tom Lane wrote:
>
> Thomas Munro writes:
> > Personally I'm mostly concerned about making it easy for new
> > contributors to get a working dev system going on a super common
> > platform without dealing with hard-to-diagnose errors, than people who
> > actually wa
On Tue, Jul 6, 2021 at 2:34 PM Tom Lane wrote:
>
> Peter Eisentraut writes:
> > I think this change is perfectly appropriate (modulo some small cleanups).
>
> I think there are a couple of issues here.
>
> 1. People who are already using MACOSX_DEPLOYMENT_TARGET to control
> their builds would li
35 matches
Mail list logo
