Re: XCode 11 on Mojave problem, again
On Nov 9, 2019, at 19:49, Al Varnell wrote: > On Nov 9, 2019, at 08:45, Ryan Schmidt wrote: Have you tried installing the CLT ? That should provide a 10.14 SDK that the latest MacPorts release will use. >>> >>> I thought CLT was installed with XCode. >> >> It was prior to Xcode 4. These days it is a separate install. We recommend >> you install it. > > That’s not what it says on the Developer Download site. Here’s a quote from > CLT for Xcode 11.2: > > “If you use Xcode, these tools are also embedded within the Xcode IDE.” I know that the tools are embedded within the Xcode IDE. That is different from installing the command line tools.
Re: XCode 11 on Mojave problem, again
Sent from my iPad On Nov 9, 2019, at 08:45, Ryan Schmidt wrote: >>> Have you tried installing the CLT ? That should provide a 10.14 SDK that >>> the latest MacPorts release will use. >> >> I thought CLT was installed with XCode. > > It was prior to Xcode 4. These days it is a separate install. We recommend > you install it. That’s not what it says on the Developer Download site. Here’s a quote from CLT for Xcode 11.2: “If you use Xcode, these tools are also embedded within the Xcode IDE.” -Al-
Re: XCode 11 on Mojave problem, again
> Am 2019-11-09 um 17:45 schrieb Ryan Schmidt : > >>> That is a bad idea, pretending a 10.15 SDK is a 10.14 one could lead to >>> unforeseen side effects. So this is not something we recommend anyone does. >> >> I’m a cowboy coder ;) > > Well, please revert the change so that it doesn't cause you trouble, since we > don't want to receive tech support questions in the future that might arise > from it. Ok. Don’t worry. >>> Have you tried installing the CLT ? That should provide a 10.14 SDK that >>> the latest MacPorts release will use. >> >> I thought CLT was installed with XCode. > > It was prior to Xcode 4. These days it is a separate install. We recommend > you install it. > >> I tried now and it didn’t change the SDKs. > > It won't change which SDKs are available in Xcode, but it will install a > separate SDK that matches your OS version in the CLT directory. Now that > you've installed the CLT, whichever port(s) you have installed that contain > baked-in references to Xcode 10's 10.14 SDK will have to be rebuilt so that > they instead use either Xcode 11's 10.15 SDK (if the port says "use_xcode > yes") or the CLT's 10.14 SDK (if not). Ah, thanks. I didn’t find them, let’s hope it’ll work. Best, Hraban
Re: XCode 11 on Mojave problem, again
On Nov 9, 2019, at 10:35, Henning Hraban Ramm wrote: > Am 2019-11-09 um 15:07 schrieb Chris Jones: > >> On 9 Nov 2019, at 1:50 pm, Henning Hraban Ramm wrote: >> >>> Since I didn’t find a way to install a 10.14 SDK, I just made a symlink to >>> the 10.15 SDK under the name of MacOSX10.14.sdk, and it works so far! >> >> That is a bad idea, pretending a 10.15 SDK is a 10.14 one could lead to >> unforeseen side effects. So this is not something we recommend anyone does. > > I’m a cowboy coder ;) Well, please revert the change so that it doesn't cause you trouble, since we don't want to receive tech support questions in the future that might arise from it. >> Have you tried installing the CLT ? That should provide a 10.14 SDK that the >> latest MacPorts release will use. > > I thought CLT was installed with XCode. It was prior to Xcode 4. These days it is a separate install. We recommend you install it. > I tried now and it didn’t change the SDKs. It won't change which SDKs are available in Xcode, but it will install a separate SDK that matches your OS version in the CLT directory. Now that you've installed the CLT, whichever port(s) you have installed that contain baked-in references to Xcode 10's 10.14 SDK will have to be rebuilt so that they instead use either Xcode 11's 10.15 SDK (if the port says "use_xcode yes") or the CLT's 10.14 SDK (if not).
Re: XCode 11 on Mojave problem, again
> Am 2019-11-09 um 15:07 schrieb Chris Jones : > >> On 9 Nov 2019, at 1:50 pm, Henning Hraban Ramm wrote: >> >> Hi, >> I also had problems on Mojave, since at least cctools was expecting a >> MacOSX10.14.sdk in >> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs; >> on Mojave there’s only the 10.15 SDK. >> I had XCode 10.something and updated yesterday to 11.latest; that needed >> some hours... >> >> Since I didn’t find a way to install a 10.14 SDK, I just made a symlink to >> the 10.15 SDK under the name of MacOSX10.14.sdk, and it works so far! > > That is a bad idea, pretending a 10.15 SDK is a 10.14 one could lead to > unforeseen side effects. So this is not something we recommend anyone does. I’m a cowboy coder ;) > Have you tried installing the CLT ? That should provide a 10.14 SDK that the > latest MacPorts release will use. I thought CLT was installed with XCode. I tried now and it didn’t change the SDKs. HR
Re: XCode 11 on Mojave problem, again
> On 9 Nov 2019, at 1:50 pm, Henning Hraban Ramm wrote: > > Hi, > I also had problems on Mojave, since at least cctools was expecting a > MacOSX10.14.sdk in > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs; > on Mojave there’s only the 10.15 SDK. > I had XCode 10.something and updated yesterday to 11.latest; that needed some > hours... > > Since I didn’t find a way to install a 10.14 SDK, I just made a symlink to > the 10.15 SDK under the name of MacOSX10.14.sdk, and it works so far! That is a bad idea, pretending a 10.15 SDK is a 10.14 one could lead to unforeseen side effects. So this is not something we recommend anyone does. Have you tried installing the CLT ? That should provide a 10.14 SDK that the latest MacPorts release will use. > All the ports that didn’t compile previously, like cctools, ImageMagick, > Inkscape (maybe unrelated) and MariaDB10.* ran through. > > Greetlings, Hraban > > BTW: Hello Mojca! ;) > >> Am 2019-11-09 um 10:39 schrieb Ruben Di Battista : >> >> Ehi Mojca, >> >> Thanks for the message. :) >> >> I managed to fix it. I got confused because recently I updated Xcode, but in >> facts the problem was completely unrelated: I had a project header file >> named “math.h”. :) Very noob mistake! Interestingly enough, this bug does >> not pop-out on Linux (using GCC). >> >> So I just renamed “math.h” to a custom name, and now everything is back as >> before (Ah, pay attention! Most of macOS systems have a case-insensitive >> filesystem… I firstly renamed the file from “math.h” -> “Math.h”, but it >> didn’t work either and it took a while to realize that on macOS “math.h” and >> “Math.h” are the same if the FS is case-insensitive. >
Re: XCode 11 on Mojave problem, again
Hi, I also had problems on Mojave, since at least cctools was expecting a MacOSX10.14.sdk in /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs; on Mojave there’s only the 10.15 SDK. I had XCode 10.something and updated yesterday to 11.latest; that needed some hours... Since I didn’t find a way to install a 10.14 SDK, I just made a symlink to the 10.15 SDK under the name of MacOSX10.14.sdk, and it works so far! All the ports that didn’t compile previously, like cctools, ImageMagick, Inkscape (maybe unrelated) and MariaDB10.* ran through. Greetlings, Hraban BTW: Hello Mojca! ;) > Am 2019-11-09 um 10:39 schrieb Ruben Di Battista : > > Ehi Mojca, > > Thanks for the message. :) > > I managed to fix it. I got confused because recently I updated Xcode, but in > facts the problem was completely unrelated: I had a project header file named > “math.h”. :) Very noob mistake! Interestingly enough, this bug does not > pop-out on Linux (using GCC). > > So I just renamed “math.h” to a custom name, and now everything is back as > before (Ah, pay attention! Most of macOS systems have a case-insensitive > filesystem… I firstly renamed the file from “math.h” -> “Math.h”, but it > didn’t work either and it took a while to realize that on macOS “math.h” and > “Math.h” are the same if the FS is case-insensitive. signature.asc Description: Message signed with OpenPGP
Re: XCode 11 on Mojave problem, again
Ehi Mojca,
Thanks for the message. :)
I managed to fix it. I got confused because recently I updated Xcode, but in
facts the problem was completely unrelated: I had a project header file named
“math.h”. :) Very noob mistake! Interestingly enough, this bug does not pop-out
on Linux (using GCC).
So I just renamed “math.h” to a custom name, and now everything is back as
before (Ah, pay attention! Most of macOS systems have a case-insensitive
filesystem… I firstly renamed the file from “math.h” -> “Math.h”, but it didn’t
work either and it took a while to realize that on macOS “math.h” and “Math.h”
are the same if the FS is case-insensitive.
In any case thanks for your help! :)
_
-. .´ |
', ;|∞∞
˜˜ |∞ RdB
,.,|∞∞
.' '. |
-' `’
https://rdb.is
On 8 November 2019 at 18:32:13, Mojca Miklavec (mo...@macports.org) wrote:
Dear Ruben,
This definitely looks like a bug in Xcode. I would suggest you to file
a bug report to Apple.
Can you please try to compile a simple hello world with just the
following contents
// test.cpp:
#include
int main() { return 0; }
and compile it with:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
test.cpp \
-isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk
Mojca
On Fri, 8 Nov 2019 at 15:27, Ruben Di Battista
wrote:
>
> Hello people,
>
> I saw this kind of errors quite often lately around. But this times I’m
> hitting this with a local project, not a port in Macports. A project that
> used to build correctly with Xcode 10, now it seems to miss stuff in
> header.
>
> ninja -j 1
> [1/48] Building CXX object src/libs/CMakeFiles/Mercurve.dir/BlockMerger.cxx.o
>
> FAILED: src/libs/CMakeFiles/Mercurve.dir/BlockMerger.cxx.o
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
> -DMercurve_EXPORTS -I../src/libs -isystem /opt/local/include/vtk-8.1
> -isystem /opt/local/include -isystem /opt/local/include/mpich-mp -isystem
> /opt/local/include/libxml2 -g -isysroot
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk
> -mmacosx-version-min=10.14 -fPIC -Wall -Wno-long-long -pedantic
> -fcolor-diagnostics -std=gnu++11 -MD -MT
> src/libs/CMakeFiles/Mercurve.dir/BlockMerger.cxx.o -MF
> src/libs/CMakeFiles/Mercurve.dir/BlockMerger.cxx.o.d -o
> src/libs/CMakeFiles/Mercurve.dir/BlockMerger.cxx.o -c
> ../src/libs/BlockMerger.cxx
> In file included from ../src/libs/BlockMerger.cxx:21:
> In file included from ../src/libs/BlockMerger.h:28:
> In file included from ../src/libs/types.h:25:
> In file included from
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/unordered_set:363:
>
> In file included from
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__hash_table:19:
>
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath:314:9:
> error: no member named 'signbit' in the global namespace
> […]
>
> I read a bit the tickets of other ports, but they don’t fit exactly with what
> I have. Any fast hint? Do I need to downgrade Xcode?
>
> _
> -. .´ |
> ', ; |∞∞
> ˜˜ |∞ RdB
> ,., |∞∞
> .' '. |
> -' `’
>
> https://rdb.is
signature.asc
Description: Message signed with OpenPGP using AMPGpg
Re: XCode 11 on Mojave problem, again
Dear Ruben,
This definitely looks like a bug in Xcode. I would suggest you to file
a bug report to Apple.
Can you please try to compile a simple hello world with just the
following contents
// test.cpp:
#include
int main() { return 0; }
and compile it with:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
test.cpp \
-isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk
Mojca
On Fri, 8 Nov 2019 at 15:27, Ruben Di Battista
wrote:
>
> Hello people,
>
> I saw this kind of errors quite often lately around. But this times I’m
> hitting this with a local project, not a port in Macports. A project that
> used to build correctly with Xcode 10, now it seems to miss stuff in
> header.
>
> ninja -j 1
> [1/48] Building CXX object src/libs/CMakeFiles/Mercurve.dir/BlockMerger.cxx.o
> FAILED: src/libs/CMakeFiles/Mercurve.dir/BlockMerger.cxx.o
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
> -DMercurve_EXPORTS -I../src/libs -isystem /opt/local/include/vtk-8.1
> -isystem /opt/local/include -isystem /opt/local/include/mpich-mp -isystem
> /opt/local/include/libxml2 -g -isysroot
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk
> -mmacosx-version-min=10.14 -fPIC -Wall -Wno-long-long -pedantic
> -fcolor-diagnostics -std=gnu++11 -MD -MT
> src/libs/CMakeFiles/Mercurve.dir/BlockMerger.cxx.o -MF
> src/libs/CMakeFiles/Mercurve.dir/BlockMerger.cxx.o.d -o
> src/libs/CMakeFiles/Mercurve.dir/BlockMerger.cxx.o -c
> ../src/libs/BlockMerger.cxx
> In file included from ../src/libs/BlockMerger.cxx:21:
> In file included from ../src/libs/BlockMerger.h:28:
> In file included from ../src/libs/types.h:25:
> In file included from
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/unordered_set:363:
> In file included from
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__hash_table:19:
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath:314:9:
> error: no member named 'signbit' in the global namespace
> […]
>
> I read a bit the tickets of other ports, but they don’t fit exactly with what
> I have. Any fast hint? Do I need to downgrade Xcode?
>
> _
> -. .´ |
> ', ;|∞∞
> ˜˜ |∞ RdB
> ,.,|∞∞
> .' '. |
> -' `’
>
> https://rdb.is
XCode 11 on Mojave problem, again
Hello people, I saw this kind of errors quite often lately around. But this times I’m hitting this with a local project, not a port in Macports. A project that used to build correctly with Xcode 10, now it seems to miss stuff in header. ninja -j 1 [1/48] Building CXX object src/libs/CMakeFiles/Mercurve.dir/BlockMerger.cxx.o FAILED: src/libs/CMakeFiles/Mercurve.dir/BlockMerger.cxx.o /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -DMercurve_EXPORTS -I../src/libs -isystem /opt/local/include/vtk-8.1 -isystem /opt/local/include -isystem /opt/local/include/mpich-mp -isystem /opt/local/include/libxml2 -g -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -mmacosx-version-min=10.14 -fPIC -Wall -Wno-long-long -pedantic -fcolor-diagnostics -std=gnu++11 -MD -MT src/libs/CMakeFiles/Mercurve.dir/BlockMerger.cxx.o -MF src/libs/CMakeFiles/Mercurve.dir/BlockMerger.cxx.o.d -o src/libs/CMakeFiles/Mercurve.dir/BlockMerger.cxx.o -c ../src/libs/BlockMerger.cxx In file included from ../src/libs/BlockMerger.cxx:21: In file included from ../src/libs/BlockMerger.h:28: In file included from ../src/libs/types.h:25: In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/unordered_set:363: In file included from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/__hash_table:19: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/cmath:314:9: error: no member named 'signbit' in the global namespace […] I read a bit the tickets of other ports, but they don’t fit exactly with what I have. Any fast hint? Do I need to downgrade Xcode? _ -. .´ | ', ;|∞∞ ˜˜ |∞ RdB ,.,|∞∞ .' '. | -' `’ https://rdb.is signature.asc Description: Message signed with OpenPGP using AMPGpg
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: 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
> > 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 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: Xcode 11 on Mojave
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.
Xcode 11 on Mojave (was: libSystem not found using gfortran)
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. - Josh Chris Jones wrote: > yes, as it only has the 10.15 SDK, different to the 10.14 one Xcode 10 > has, which the buildbots use. > > On 11/10/2019 2:56 pm, Richard L. Hamilton wrote: >> Is Xcode 11.1 still a bad idea on Mojave?
