Jakob Egger writes:
> Then I upgraded the "Comand Line Tools for Xcode 10.1" using Software Update,
> and suddenly the "-isysroot" flag disappeared (for both Xcode 10 and Xcode
> 10.1).
Interesting. I'd not tested the intermediate state without the CLT
update.
> In any case, it looks like we
> Am 1. Nov. 2018 um 04:17 schrieb Tom Lane :
>
> You can verify the thing's built-in settings with something like
>
> $ echo >test.c
> $ clang -v -E test.c
>
> and on Xcode 10.0 I get
>
> "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang"
> -cc1 -t
Daniel Gustafsson writes:
>> On 2 Nov 2018, at 15:42, Tom Lane wrote:
>> Anybody have an opinion about which approach to use? We need to choose
>> one, and PDQ too, if we want full buildfarm coverage on it before Monday's
>> wrap.
> #1 is the option that appeals to me the most, mostly because i
> On 2 Nov 2018, at 15:42, Tom Lane wrote:
>
> I wrote:
>> Here's a lightly-tested patch for that approach.
>
> Anybody have an opinion about which approach to use? We need to choose
> one, and PDQ too, if we want full buildfarm coverage on it before Monday's
> wrap.
Sorry for being slow to
I wrote:
> Here's a lightly-tested patch for that approach.
Anybody have an opinion about which approach to use? We need to choose
one, and PDQ too, if we want full buildfarm coverage on it before Monday's
wrap.
The main argument in favor of #1 (restore use of -isysroot) is fear that
Apple's goi
I wrote:
> Then somebody who wants to build on a different SDK version still needs
> to do "make PG_SYSROOT=/proper/path", but only if they're trying to
> build PL/Perl or related extensions. So this second way seems uglier
> in some sense but less likely to cause problems for most people.
> Eith
I wrote:
> Peter Eisentraut writes:
>> On 01/11/2018 22:17, Tom Lane wrote:
>>> The other idea that's occurred to me is to go back to the scheme of
>>> commit 68fc227dd, where we inject the sysroot path into just the -I
>>> switches used for PL/Perl and PL/Tcl. We could improve on that
>>> commit
Peter Eisentraut writes:
> On 01/11/2018 22:17, Tom Lane wrote:
>> The other idea that's occurred to me is to go back to the scheme of
>> commit 68fc227dd, where we inject the sysroot path into just the -I
>> switches used for PL/Perl and PL/Tcl. We could improve on that
>> commit by injecting it
On 01/11/2018 22:17, Tom Lane wrote:
> The other idea that's occurred to me is to go back to the scheme of
> commit 68fc227dd, where we inject the sysroot path into just the -I
> switches used for PL/Perl and PL/Tcl. We could improve on that
> commit by injecting it symbolically similar to what I
So it seems like there are two ways we could go about this. One is
to go back to the scheme of adding an -isysroot switch to CPPFLAGS,
where it'd have global effects. We could make this slightly less
painful for scenarios like Jakob's if we set things up in Makefile.global
this way:
CPPFLAGS = -
> On 1 Nov 2018, at 15:53, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>>> On 1 Nov 2018, at 15:14, Tom Lane wrote:
>>> Wow ... could it be that it actually varies depending on the combination
>>> of compiler and OS versions? That would be weird.
>
>> Or the version of XCode and the set of
Daniel Gustafsson writes:
>> On 1 Nov 2018, at 15:14, Tom Lane wrote:
>> Wow ... could it be that it actually varies depending on the combination
>> of compiler and OS versions? That would be weird.
> Or the version of XCode and the set of installed SDKs? I only have a single
> SDK installed o
> On 1 Nov 2018, at 15:14, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>> Odd. I don’t actually get -isysroot on XCode 10.0 on my 10.13.6
>> installation,
>> on 10.12 with XCode 8.3.3 I do however get -isysroot.
>
> Wow ... could it be that it actually varies depending on the combination
>
Daniel Gustafsson writes:
> Odd. I don’t actually get -isysroot on XCode 10.0 on my 10.13.6 installation,
> on 10.12 with XCode 8.3.3 I do however get -isysroot.
Wow ... could it be that it actually varies depending on the combination
of compiler and OS versions? That would be weird.
> On 1 Nov 2018, at 04:17, Tom Lane wrote:
> and on Xcode 10.0 I get
Odd. I don’t actually get -isysroot on XCode 10.0 on my 10.13.6 installation,
on 10.12 with XCode 8.3.3 I do however get -isysroot.
> Right now I think the only plausible
> fix is to go back to adding "-isysroot $PG_SYSROOT"
[ just when you thought it was safe to go back in the water ]
I wrote:
>> Jakob Egger writes:
>>> I would assume that clang sets -isysroot automatically, but I have no idea
>>> why that didn't work for you previously.
>> [ experiments further ... ] It looks like clang does default to assuming
I wrote:
> Jakob Egger writes:
>> I would assume that clang sets -isysroot automatically, but I have no idea
>> why that didn't work for you previously.
> [ experiments further ... ] It looks like clang does default to assuming
> -isysroot with the correct sysroot for its Xcode version. The mi
Jakob Egger writes:
> Am 17.10.2018 um 16:28 schrieb Tom Lane :
>> It's also very odd,
>> if the compiler will search the sysroot automatically, why that seemingly
>> works for tcl.h but not perl.h. plperl definitely still fails if you
>> lobotomize the PG_SYSROOT logic.
> Because pl/tcl ends up
Am 17.10.2018 um 16:28 schrieb Tom Lane :
> It's also very odd,
> if the compiler will search the sysroot automatically, why that seemingly
> works for tcl.h but not perl.h. plperl definitely still fails if you
> lobotomize the PG_SYSROOT logic.
Because pl/tcl ends up using -iwithsysroot to spec
Jakob Egger writes:
> Am 16. Okt. 2018 um 17:13 schrieb Tom Lane :
>> Oh, well *this* is interesting. I stated at the top of this thread that
>> pltcl doesn't build on Mojave without -isysroot because TCL_INCLUDE_SPEC
>> gets set to
>> -iwithsysroot /System/Library/Frameworks/Tcl.framework/Versio
Am 16. Okt. 2018 um 17:13 schrieb Tom Lane :
> Oh, well *this* is interesting. I stated at the top of this thread that
> pltcl doesn't build on Mojave without -isysroot because TCL_INCLUDE_SPEC
> gets set to
> -iwithsysroot
> /System/Library/Frameworks/Tcl.framework/Versions/8.5/Headers
>
I wrote:
> If we go this route, then the configure-time sysroot path will get
> embedded into $perl_includedir and $TCL_INCLUDE_SPEC, but noplace
> else. I don't know how far that would improve your concern about
> extensions, but it should help a little.
> I'm still a bit dubious about the safety
I wrote:
> Jakob Egger writes:
>> Am 25. Sep. 2018 um 06:49 schrieb Tom Lane :
>>> It's a bit scary to be adding -isysroot globally.
>> This breaks building extensions with a different SDK than the server itself.
> Hm, under what circumstances would that be safe or a good idea?
Oh, well *this*
Jakob Egger writes:
> Am 25. Sep. 2018 um 06:49 schrieb Tom Lane :
>> It's a bit scary to be adding -isysroot globally.
> This breaks building extensions with a different SDK than the server itself.
Hm, under what circumstances would that be safe or a good idea?
The concerns that strike my mind
Am 25. Sep. 2018 um 06:49 schrieb Tom Lane :
> It's a bit scary to be adding -isysroot globally.
> (...)
> I've tested this on all the macOS versions I have at hand, and it
> doesn't seem to break anything.
> (...)
> Thoughts?
>
> regards, tom lane
This breaks building ext
Thomas Munro writes:
> ... and now I'm on macOS 10.14. I removed all traces of MacPorts from
> my PATH and configure line to test this. --with-tcl worked, but
> --with-perl couldn't find "perl.h". Then I realised that it was
> because I was still on Xcode 9, so I was in for another ~5GB of
> up
On Wed, Sep 26, 2018 at 3:14 AM Tom Lane wrote:
> Thomas Munro writes:
> > On Tue, Sep 25, 2018 at 4:49 PM Tom Lane wrote:
> >> I've tested this on all the macOS versions I have at hand, and it
> >> doesn't seem to break anything. Only part (1) could possibly
> >> affect other platforms, and th
Thomas Munro writes:
> On Tue, Sep 25, 2018 at 4:49 PM Tom Lane wrote:
>> I've tested this on all the macOS versions I have at hand, and it
>> doesn't seem to break anything. Only part (1) could possibly
>> affect other platforms, and that seems safe enough.
>>
>> I'd like to commit and backpat
On Tue, Sep 25, 2018 at 4:49 PM Tom Lane wrote:
> I've tested this on all the macOS versions I have at hand, and it
> doesn't seem to break anything. Only part (1) could possibly
> affect other platforms, and that seems safe enough.
>
> I'd like to commit and backpatch this, because otherwise lon
Well, macOS 10.14 (Mojave) is out, so I installed it on a spare machine,
and naturally the first thing I tried was to build PG with it. Our
core code seems fine, but:
* --with-perl fails in configure, complaining that it can't find perl.h.
* --with-tcl fails in configure, complaining that it can
30 matches
Mail list logo
