Re: Xcode 11 on Mojave
> On 12 Oct 2019, at 3:28 am, Ryan Schmidt wrote: > > On Oct 11, 2019, at 09:57, Joshua Root wrote: > >> Xcode itself only contains a 10.15 SDK, but the Command Line Tools have >> a 10.14 one. You should be mostly fine with them installed, though there >> are some exceptions. Our installation instructions have always said to >> install both Xcode and the CLTs. > > But the CLT has the SDK in a different path than Xcode does, of course. And > if Xcode-based SDK paths got baked into various ports on our Xcode-10-using > Mojave build worker, then that will be a problem for any users that have > Xcode 11, whether or not they have the CLT. Does the 10.14 buildbot have the CLT installed ? If not, maybe adding it would help ? >
Re: compiler warning
> On Oct 12, 2019, at 10:10 AM, Ryan Schmidt wrote: > > On Oct 11, 2019, at 23:11, Andrew Hartung wrote: > >> On Oct 11, 2019, at 9:39 PM, Ryan Schmidt wrote: > >>> On Oct 10, 2019, at 22:58, Andrew Hartung wrote: >>> Warning: All compilers are either blacklisted or unavailable; defaulting to first fallback option >>> >>> llvm, clang, and lldb are all part of the same software package. >>> >>> Different ports impose different restrictions on the versions of compilers >>> they can be built with. According to the llvm-9.0 portfile, llvm-9.0 and >>> clang-9.0 blacklist clang < 602 while lldb-9.0 blacklists clang < 700. >>> >>> The message you received means that, after applying the blacklist, no >>> suitable compiler remains. That should not be the case with Xcode 10; you >>> should have clang 1000 or newer, which should be fine. What version of >>> clang do you actually have? Run >>> >>> /usr/bin/clang --version >>> >>> to find out. If it's less than 1000, try (re)installing the command line >>> tools. >>> >>> If that's not it, the compiler blacklist versions portgroup was recently >>> changed. Maybe in doing so we introduced a bug. >>> >> >> ~ $ /usr/bin/clang --version >> Apple clang version 11.0.0 (clang-1100.0.33.8) >> Target: x86_64-apple-darwin18.7.0 >> Thread model: posix >> InstalledDir: >> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin > > Clang 11 goes with Xcode 11 but you said you have Xcode 10. You should either > upgrade to Xcode 11 to match your clang version (I don't recommend this due > to the many problems we've seen with SDK paths) or you should downgrade your > Clang version (that is to say, your command line tools version) to match your > Xcode version. > How do I do that? > >> I had not changed/updated anything related to xcode since I had last >> accepted the xcode license, so maybe there has been a bug introduced. > > Possibly. I am not able to investigate this right now. Maybe somebody else > can.
Re: compiler warning
Remember to Reply All so the conversation stays on the list. On Oct 11, 2019, at 23:11, Andrew Hartung wrote: > On Oct 11, 2019, at 9:39 PM, Ryan Schmidt wrote: >> On Oct 10, 2019, at 22:58, Andrew Hartung wrote: >> >>> >>> Warning: All compilers are either blacklisted or unavailable; defaulting to >>> first fallback option >> >> llvm, clang, and lldb are all part of the same software package. >> >> Different ports impose different restrictions on the versions of compilers >> they can be built with. According to the llvm-9.0 portfile, llvm-9.0 and >> clang-9.0 blacklist clang < 602 while lldb-9.0 blacklists clang < 700. >> >> The message you received means that, after applying the blacklist, no >> suitable compiler remains. That should not be the case with Xcode 10; you >> should have clang 1000 or newer, which should be fine. What version of clang >> do you actually have? Run >> >> /usr/bin/clang --version >> >> to find out. If it's less than 1000, try (re)installing the command line >> tools. >> >> If that's not it, the compiler blacklist versions portgroup was recently >> changed. Maybe in doing so we introduced a bug. >> > > ~ $ /usr/bin/clang --version > Apple clang version 11.0.0 (clang-1100.0.33.8) > Target: x86_64-apple-darwin18.7.0 > Thread model: posix > InstalledDir: > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin Clang 11 goes with Xcode 11 but you said you have Xcode 10. You should either upgrade to Xcode 11 to match your clang version (I don't recommend this due to the many problems we've seen with SDK paths) or you should downgrade your Clang version (that is to say, your command line tools version) to match your Xcode version. > I had not changed/updated anything related to xcode since I had last accepted > the xcode license, so maybe there has been a bug introduced. Possibly. I am not able to investigate this right now. Maybe somebody else can.
All compilers are either blacklisted or unavailable (was: compiler warning)
Ryan Schmidt wrote:
> On Oct 11, 2019, at 23:11, Andrew Hartung wrote:
>
>> On Oct 11, 2019, at 9:39 PM, Ryan Schmidt wrote:
>
>>> On Oct 10, 2019, at 22:58, Andrew Hartung wrote:
>>>
Warning: All compilers are either blacklisted or unavailable; defaulting
to first fallback option
>>>
>>> llvm, clang, and lldb are all part of the same software package.
>>>
>>> Different ports impose different restrictions on the versions of compilers
>>> they can be built with. According to the llvm-9.0 portfile, llvm-9.0 and
>>> clang-9.0 blacklist clang < 602 while lldb-9.0 blacklists clang < 700.
>>>
>>> The message you received means that, after applying the blacklist, no
>>> suitable compiler remains. That should not be the case with Xcode 10; you
>>> should have clang 1000 or newer, which should be fine. What version of
>>> clang do you actually have? Run
>>>
>>> /usr/bin/clang --version
>>>
>>> to find out. If it's less than 1000, try (re)installing the command line
>>> tools.
>>>
>>> If that's not it, the compiler blacklist versions portgroup was recently
>>> changed. Maybe in doing so we introduced a bug.
>>>
>>
>> ~ $ /usr/bin/clang --version
>> Apple clang version 11.0.0 (clang-1100.0.33.8)
>> Target: x86_64-apple-darwin18.7.0
>> Thread model: posix
>> InstalledDir:
>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
>
> Clang 11 goes with Xcode 11 but you said you have Xcode 10. You should either
> upgrade to Xcode 11 to match your clang version (I don't recommend this due
> to the many problems we've seen with SDK paths) or you should downgrade your
> Clang version (that is to say, your command line tools version) to match your
> Xcode version.
>
>
>> I had not changed/updated anything related to xcode since I had last
>> accepted the xcode license, so maybe there has been a bug introduced.
>
> Possibly. I am not able to investigate this right now. Maybe somebody else
> can.
Run any command that parses the portfile with the -d option. 'port -d
info llvm-9.0' for example. You will see a lot of debug output, some of
which is from compiler_blacklist_versions. I see this:
DEBUG: compiler clang 1100.0.33.8 not blacklisted because it doesn't
match {clang < 602}
- JOsh
Re: compiler warning
I found the problem. Somehow xcode got updated to 11 automatically two days ago. I just upgraded to Mojave a couple of weeks ago and missed a setting in the app store to turn off automatic upgrades. Downgrading now, sorry to waste everyones time. > On Oct 12, 2019, at 10:10 AM, Ryan Schmidt wrote: > > > On Oct 11, 2019, at 23:11, Andrew Hartung wrote: > >> On Oct 11, 2019, at 9:39 PM, Ryan Schmidt wrote: > >>> On Oct 10, 2019, at 22:58, Andrew Hartung wrote: >>> Warning: All compilers are either blacklisted or unavailable; defaulting to first fallback option >>> >>> llvm, clang, and lldb are all part of the same software package. >>> >>> Different ports impose different restrictions on the versions of compilers >>> they can be built with. According to the llvm-9.0 portfile, llvm-9.0 and >>> clang-9.0 blacklist clang < 602 while lldb-9.0 blacklists clang < 700. >>> >>> The message you received means that, after applying the blacklist, no >>> suitable compiler remains. That should not be the case with Xcode 10; you >>> should have clang 1000 or newer, which should be fine. What version of >>> clang do you actually have? Run >>> >>> /usr/bin/clang --version >>> >>> to find out. If it's less than 1000, try (re)installing the command line >>> tools. >>> >>> If that's not it, the compiler blacklist versions portgroup was recently >>> changed. Maybe in doing so we introduced a bug. >>> >> >> ~ $ /usr/bin/clang --version >> Apple clang version 11.0.0 (clang-1100.0.33.8) >> Target: x86_64-apple-darwin18.7.0 >> Thread model: posix >> InstalledDir: >> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin > > Clang 11 goes with Xcode 11 but you said you have Xcode 10. You should either > upgrade to Xcode 11 to match your clang version (I don't recommend this due > to the many problems we've seen with SDK paths) or you should downgrade your > Clang version (that is to say, your command line tools version) to match your > Xcode version. > > >> I had not changed/updated anything related to xcode since I had last >> accepted the xcode license, so maybe there has been a bug introduced. > > Possibly. I am not able to investigate this right now. Maybe somebody else > can.
Re: Xcode 11 on Mojave
> > But the CLT has the SDK in a different path than Xcode does, of course. And > > if Xcode-based SDK paths got baked into various ports on our Xcode-10-using > > Mojave build worker, then that will be a problem for any users that have > > Xcode 11, whether or not they have the CLT. > > Does the 10.14 buildbot have the CLT installed ? If not, maybe adding it > would help ? Yeah, this is our /path/to/SDK problem. If the supported configuration for MacPorts is to have the command line tools installed, and if the buildbots and the users all have the command line tools installed, we should never see any more /path/to/SDK errors. And any ports on the buildbot that currently have a /path/to/SDK that points into Xcode will just need to be revbumped to fix it to pointing to the Command Line Tools path instead. Ken
Re: Xcode 11 on Mojave
On Oct 12, 2019, at 03:36, Chris Jones wrote: > On 12 Oct 2019, at 3:28 am, Ryan Schmidt wrote: > >> On Oct 11, 2019, at 09:57, Joshua Root wrote: >> >>> Xcode itself only contains a 10.15 SDK, but the Command Line Tools have >>> a 10.14 one. You should be mostly fine with them installed, though there >>> are some exceptions. Our installation instructions have always said to >>> install both Xcode and the CLTs. >> >> But the CLT has the SDK in a different path than Xcode does, of course. And >> if Xcode-based SDK paths got baked into various ports on our Xcode-10-using >> Mojave build worker, then that will be a problem for any users that have >> Xcode 11, whether or not they have the CLT. > > Does the 10.14 buildbot have the CLT installed ? If not, maybe adding it > would help ? At the time that 10.14 was released, the word was that we wanted to support MacPorts with Xcode only, without the CLT. Therefore the 10.14 buildbot worker is the first one on which I installed only Xcode and not the CLT. Now Joshua has said we are changing our minds on this, and therefore I should install the CLT on the 10.14 buildbot worker. It is still running Xcode 10, and given all the problems we're seeing with SDK paths, it seems like I should keep it on Xcode 10 and not upgrade it to 11.
Re: Xcode 11 on Mojave
On 2019-10-13 02:06 , Ryan Schmidt wrote: > > > On Oct 12, 2019, at 03:36, Chris Jones wrote: > >> On 12 Oct 2019, at 3:28 am, Ryan Schmidt wrote: >> >>> On Oct 11, 2019, at 09:57, Joshua Root wrote: >>> Xcode itself only contains a 10.15 SDK, but the Command Line Tools have a 10.14 one. You should be mostly fine with them installed, though there are some exceptions. Our installation instructions have always said to install both Xcode and the CLTs. >>> >>> But the CLT has the SDK in a different path than Xcode does, of course. And >>> if Xcode-based SDK paths got baked into various ports on our Xcode-10-using >>> Mojave build worker, then that will be a problem for any users that have >>> Xcode 11, whether or not they have the CLT. >> >> Does the 10.14 buildbot have the CLT installed ? If not, maybe adding it >> would help ? > > At the time that 10.14 was released, the word was that we wanted to support > MacPorts with Xcode only, without the CLT. Therefore the 10.14 buildbot > worker is the first one on which I installed only Xcode and not the CLT. > > Now Joshua has said we are changing our minds on this, and therefore I should > install the CLT on the 10.14 buildbot worker. > > It is still running Xcode 10, and given all the problems we're seeing with > SDK paths, it seems like I should keep it on Xcode 10 and not upgrade it to > 11. There shouldn't be a problem using Xcode 11 if the CLTs are installed. Their 10.14 SDK will be used preferentially as of MacPorts 2.6. - Josh
Re: MacPorts activation relating to bsdtar
> On 12 Oct 2019, at 3:26 am, Ryan Schmidt wrote: > > > >> On Oct 11, 2019, at 10:49, Steven Esser wrote: >> >> On a fresh Catalina (10.15) install with Xcode 11.1 and the latest CLI tools >> I cannot seem to activate any ports. Most seem to configure and build >> correctly, but fail when they reach the activation step. Attached is the log >> for an attempted installation of ncurses that has this activation step >> failure and occurs no matter what the port. >> >> From the log itself, it looks like bsdtar is the culprit? Bsdtar fails with >> this command "Command failed: /usr/bin/bzip2 -d -c >> /Users/sesser/MacPorts/var/macports/software/ncurses/ncurses-6.1_0.darwin_19.x86_64.tbz2 >> | ( bsdtar -xvp --hfsCompression -f - )” >> >> This is the bsdtar found at /usr/bin/bsdtar. >> >> Wanted to post this here to make sure there wasn’t a quick fix etc for this >> before I file a formal bug. >> >> > > Does the bsdtar command seem to work when you do things with it manually on > the command line? > > The log shows you have installed MacPorts into a custom prefix > /Users/sesser/MacPorts. Any particular reason? It's recommended to use the > standard /opt/local prefix so that you can benefit from our binaries, once > they become available. Also, it appears like you are using an area in your own user home area. I am not sure this is a good idea either, as macports needs to be able to control permissions on this area, and we have seen cases before where directories directly in the user home area have issues in this regard. I personally would recommend placing the installation elsewhere, and agree with Ryan using the default location is by far the best option. Chris > > The log shows that hfsCompression is being used. Up to Mojave, Apple's bsdtar > didn't support hfsCompression. I haven't checked Catalina yet so it's > possible that they've finally added it. But is it perhaps possible that you > have a different bsdtar somewhere else on your system that MacPorts is using, > and that other bsdtar isn't working? >
Re: MacPorts activation relating to bsdtar
Home directory installations have worked fine for me for years in the past. I understand some ports will not work, but everything I need to use works fine. That being said, I will try a few different things out to see if that fixes my problems. > On Oct 12, 2019, at 05:20, Chris Jones wrote: > > > >> On 12 Oct 2019, at 3:26 am, Ryan Schmidt wrote: >> >> >> On Oct 11, 2019, at 10:49, Steven Esser wrote: >>> >>> On a fresh Catalina (10.15) install with Xcode 11.1 and the latest CLI >>> tools I cannot seem to activate any ports. Most seem to configure and build >>> correctly, but fail when they reach the activation step. Attached is the >>> log for an attempted installation of ncurses that has this activation step >>> failure and occurs no matter what the port. >>> >>> From the log itself, it looks like bsdtar is the culprit? Bsdtar fails with >>> this command "Command failed: /usr/bin/bzip2 -d -c >>> /Users/sesser/MacPorts/var/macports/software/ncurses/ncurses-6.1_0.darwin_19.x86_64.tbz2 >>> | ( bsdtar -xvp --hfsCompression -f - )” >>> >>> This is the bsdtar found at /usr/bin/bsdtar. >>> >>> Wanted to post this here to make sure there wasn’t a quick fix etc for this >>> before I file a formal bug. >>> >>> >> >> Does the bsdtar command seem to work when you do things with it manually on >> the command line? >> >> The log shows you have installed MacPorts into a custom prefix >> /Users/sesser/MacPorts. Any particular reason? It's recommended to use the >> standard /opt/local prefix so that you can benefit from our binaries, once >> they become available. > > Also, it appears like you are using an area in your own user home area. I am > not sure this is a good idea either, as macports needs to be able to control > permissions on this area, and we have seen cases before where directories > directly in the user home area have issues in this regard. I personally would > recommend placing the installation elsewhere, and agree with Ryan using the > default location is by far the best option. > > Chris >> >> The log shows that hfsCompression is being used. Up to Mojave, Apple's >> bsdtar didn't support hfsCompression. I haven't checked Catalina yet so it's >> possible that they've finally added it. But is it perhaps possible that you >> have a different bsdtar somewhere else on your system that MacPorts is >> using, and that other bsdtar isn't working? >> >
Re: compiler warning
> On Oct 12, 2019, at 4:48 PM, Ryan Schmidt wrote: > > > > On Oct 12, 2019, at 12:30, Andrew Hartung wrote: > >> I found the problem. Somehow xcode got updated to 11 automatically two days >> ago. I just upgraded to Mojave a couple of weeks ago and missed a setting in >> the app store to turn off automatic upgrades. Downgrading now, sorry to >> waste everyones time. > > Did downgrading to Xcode 10 make the warning disappear? > The warnings disappeared when I ran xcodebuild -license with xcode 11 still installed. > You shouldn't have seen those warnings for those ports with either Xcode 10 > or 11, so there may still be something we have to fix. >
Re: compiler warning
On Oct 12, 2019, at 12:30, Andrew Hartung wrote: > I found the problem. Somehow xcode got updated to 11 automatically two days > ago. I just upgraded to Mojave a couple of weeks ago and missed a setting in > the app store to turn off automatic upgrades. Downgrading now, sorry to waste > everyones time. Did downgrading to Xcode 10 make the warning disappear? You shouldn't have seen those warnings for those ports with either Xcode 10 or 11, so there may still be something we have to fix.
Xfce4 Won't Launch in macOS Catalina
I recently upgraded from Mojave to Catalina and redid my MacPorts installation. I used Xfce4 as a WM under Mojave, but now I can’t get it to launch while running Catalina. I have attached screen shots of the errors I get. I can use quartz-wm with X11, but I would like to get Xfce4 working. Thanks, Emily
Re: compiler warning
I feel certain that could be configured to be the default setting for this list. It is the only one of over a dozen that I subscribe to where it’s not. Could that be checked into? Sent from my iPad -Al- > On Oct 12, 2019, at 08:10, Ryan Schmidt wrote: > > Remember to Reply All so the conversation stays on the list.
Re: Xfce4 Won't Launch in macOS Catalina
Hi, I am not sure you have provided enough information for anyone to really be able to help. Most likely some command that previously worked is now failing to run, and you need to first figure out what that is. Are there any crash reports, in Console, that might help ? Have you checked to see if its any of the specific possible causes mentioned in those pop ups ? Cheers Chris >> On 13 Oct 2019, at 1:39 am, Emily Jackson wrote: > I recently upgraded from Mojave to Catalina and redid my MacPorts > installation. I used Xfce4 as a WM under Mojave, but now I can’t get it to > launch while running Catalina. I have attached screen shots of the errors I > get. I can use quartz-wm with X11, but I would like to get Xfce4 working. > > Thanks, > > Emily > >
