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
