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 the "command line tools"
> > >> installed is
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 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
1.1G /Library/Developer/CommandLineTools
$ du -hs /Applications/Xcode.app
On 23.01.2021 08:02, Sergey Shinderuk wrote:
I checked the script [1], and it really requires the CLT. Here is the
explanation [2] for this:
There is actually no such requirement. However, there are
formulae that will be forced to build from source if you do not
have the CLT.
On 22.01.2021 20:12, Tom Lane wrote:
[ pokes more carefully... ] Ah-hah, I see why I needed the CLT.
I bet you'll find that you can't build from "git clean -dfx" state
with only Xcode, because comparing the contents of
/Applications/Xcode.app/Contents/Developer/usr/bin and
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. AFAIK you have to have
> >> that in order to
Sergey Shinderuk writes:
> If I run the Homebrew installer, it says that it's going to install the
> Command Line Tools. I don't know why it needs them, all the tools are
> there already. I thought that CLT is a lighter-weight option when you
> don't want the full Xcode installation, but
Sergey Shinderuk writes:
> I rejected to install CLT and abandoned Homebrew. Then I just cloned and
> built Postgres successfully. So it looks like Xcode is really enough, at
> least on a recent macOS version.
Hm. I seem to recall having had to install CLT as well as Xcode back
in the day,
On 22.01.2021 01:17, 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 the "command line tools"
installed is interesting for our purposes. AFAIK you have
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. AFAIK you have to have
> >> that in order to
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. AFAIK you have to have
>> that in order to have access to required tools like bison and gmake.
>> (That
On 21.01.2021 02:07, Tom Lane wrote:
I now believe what is actually happening with the short command is
that it's iterating through the available SDKs (according to some not
very clear search path) and picking the first one it finds that
matches the host system version. That matches the ktrace
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"
> >> agrees with the compiler's default
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"
>> agrees with the compiler's default -isysroot path as seen in the
>> compiler's -v output. I suspect
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 latter may be used for IOS potentially.
>
> What
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 latter may be used for IOS potentially.
What is "potentially"? I've found no direct means to control the
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" tells us the right thing (that
> > >> is, it *does*
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 SDK) but by refusing to
> >> believe we've
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 SDK) but by refusing to
>> believe we've got the right thing, we end up picking MacOSX11.1.sdk.
>>
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 "xcrun --show-sdk-path" and
> >> "xcrun
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 "xcrun --show-sdk-path" and
>> "xcrun --sdk macosx --show-sdk-path"? What have you got under
>>
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, doesn't work, not even sure how it could
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, doesn't work, not even sure how it could possibly fix this
> issue at all,
It worked for me and for
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-aliasing -fwrapv
> >
James Hilliard writes:
> 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
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
26 matches
Mail list logo
