User information about macOS Mojave

[Ryan Schmidt]

Apple has announced [1] that macOS Mojave (10.14) will be released on September 24, 2018. Mojave removes support for some older Macs; see the system requirements for more details [2].

As with any new macOS release, there are likely to be problems with several ports on this new macOS version, which it will take us time to identify, investigate and resolve. If you wish to help us with that, and you're OK with not being able to use some ports for a time, feel free to upgrade to Mojave when it's released and please send us bug report tickets or pull requests for anything that's broken.

We will set up a Mojave builder for our automated build system. Once we do, it will take weeks to build binaries of ports for Mojave. Until they're built, you should expect port installations to take more time, since more ports will need to be compiled on your computer.

If you'd prefer to run into fewer problems and want more things to just work, I recommend not upgrading to Mojave for at least a month after release.

One specific change in Mojave is the deprecation of 32-bit software. Mojave can run existing 32-bit software but can't build 32-bit software anymore [3] so MacPorts can't offer 32-bit software on Mojave. To see if this will affect you, you can get a list of the ports that you've installed with 32-bit parts by running:

port -qv installed | grep "archs=.*i386"

You won't be able to install most of those ports with 32-bit parts on Mojave. If that's a problem, don't upgrade to Mojave until 64-bit versions are available. For ports listed as being installed universal for i386 and x86_64, in most cases, you'll still be able to install them on Mojave, but only for x86_64.

-Ryan


[1] https://www.apple.com/macos/mojave/

[2] https://beta.apple.com/sp/betaprogram/faq#supported_hardware

[3] https://developer.apple.com/documentation/xcode_release_notes/xcode_10_release_notes

[Julien Salort]

Post by Ryan Schmidt
One specific change in Mojave is the deprecation of 32-bit software. Mojave can run existing 32-bit software but can't build 32-bit software anymore [3] so MacPorts can't offer 32-bit software on Mojave.

I don't need it, but out of curiosity, what exactely isn't provided by
Apple that prevents building 32-bits software?
Why is it not possible to build 32-bit software with a Macports version
of gcc, linked against Macports version of libraries?

Julien

[Vincent Habchi]

Post by Ryan Schmidt
One specific change in Mojave is the deprecation of 32-bit software. Mojave can run existing 32-bit software but can't build 32-bit software anymore [3] so MacPorts can't offer 32-bit software on Mojave.

I don't need it, but out of curiosity, what exactely isn't provided by Apple that prevents building 32-bits software?
Why is it not possible to build 32-bit software with a Macports version of gcc, linked against Macports version of libraries?

The 10.14 SDK doesn’t embed the 32-bit libraries anymore. I suppose if you compile clang/llvm from MacPorts, you can still continue to develop i386 software, though access to Cocoa would be problematic.

V.

[m***@macports.org]

Post by Vincent Habchi

Post by Ryan Schmidt
One specific change in Mojave is the deprecation of 32-bit software. Mojave can run existing 32-bit software but can't build 32-bit software anymore [3] so MacPorts can't offer 32-bit software on Mojave.

I don't need it, but out of curiosity, what exactely isn't provided by Apple that prevents building 32-bits software?
Why is it not possible to build 32-bit software with a Macports version of gcc, linked against Macports version of libraries?

The 10.14 SDK doesn’t embed the 32-bit libraries anymore. I suppose if you compile clang/llvm from MacPorts, you can still continue to develop i386 software, though access to Cocoa would be problematic.

Using Macports clang/llvm seems like a good idea to solve the 32-bit issue for ports like Wine. If the port is Cocoa based, then it would be able to build as 64-bit only anyway.

[Ryan Schmidt]

Post by m***@macports.org

Post by Vincent Habchi

Post by Ryan Schmidt
One specific change in Mojave is the deprecation of 32-bit software. Mojave can run existing 32-bit software but can't build 32-bit software anymore [3] so MacPorts can't offer 32-bit software on Mojave.

I don't need it, but out of curiosity, what exactely isn't provided by Apple that prevents building 32-bits software?
Why is it not possible to build 32-bit software with a Macports version of gcc, linked against Macports version of libraries?

The 10.14 SDK doesn’t embed the 32-bit libraries anymore. I suppose if you compile clang/llvm from MacPorts, you can still continue to develop i386 software, though access to Cocoa would be problematic.

Using Macports clang/llvm seems like a good idea to solve the 32-bit issue for ports like Wine.

If you're able to figure out any way to do that, please let me know.

Post by m***@macports.org
If the port is Cocoa based, then it would be able to build as 64-bit only anyway.

As I explained in the other thread, wine requires its 32-bit parts.

[Ken Cunningham]

Post by Vincent Habchi
The 10.14 SDK doesn’t embed the 32-bit libraries anymore. I suppose if you compile clang/llvm from MacPorts, you can still continue to develop i386 software, though access to Cocoa would be problematic.

I haven't dived into Mojave yet, but if all the system libraries in /usr/lib and all the Frameworks are x86_64 only, then I don't see how that could work, even if you compiled against an SDK (like the 10.13 SDK) that still has i386 support.

Even gcc links into the system libs for lots of it's underpinnings.

K

[Julien Salort]

Post by Ken Cunningham
I haven't dived into Mojave yet, but if all the system libraries in /usr/lib and all the Frameworks are x86_64 only, then I don't see how that could work, even if you compiled against an SDK (like the 10.13 SDK) that still has i386 support.

I don't have Mojave and will only install it once Macports fully
supports it.
But, if I understand correctly, it is still possible to *run* 32-bits
software. Therefore, I suppose there have to be 32-bits system
librairies in /usr/lib, as well as 32-bits Frameworks.

Cocoa software is probably less of an issue than Carbon software which
never supported 64-bits AFAIK...

[Richard L. Hamilton]

Post by Ken Cunningham
I haven't dived into Mojave yet, but if all the system libraries in /usr/lib and all the Frameworks are x86_64 only, then I don't see how that could work, even if you compiled against an SDK (like the 10.13 SDK) that still has i386 support.

I don't have Mojave and will only install it once Macports fully supports it.
But, if I understand correctly, it is still possible to *run* 32-bits software. Therefore, I suppose there have to be 32-bits system librairies in /usr/lib, as well as 32-bits Frameworks.
Cocoa software is probably less of an issue than Carbon software which never supported 64-bits AFAIK...

From what I've seen running "file" on files in /System/Library/Frameworks, /Library/Frameworks, and /usr/lib on the most recent Mojave public beta, most of the frameworks in /System/Library/Frameworks and most of the .dylib in /usr/lib are dual architecture. Frameworks in /Library (less essential or 3rd party) are mostly x86_64 only.

So I think that the 10.13 SDK on Mojave, assuming one can still build against it there, may well be a short-term answer.

But IMO, this is still a good excuse to at least get STARTED on pushing everything toward x86_64, even if workarounds are still mostly possible; because in the next OS version, i386 will likely be gone or severely crippled. I'd think that's true to the point that everything that can be x86_64 only (and is not a dependency of something that can't yet be) should be.

Note: I haven't actually tried to build anything on Mojave, didn't really want to suck up the disk space on a sparse VM (Parallels) image for Xcode etc.

[Ryan Schmidt]

Post by Richard L. Hamilton
So I think that the 10.13 SDK on Mojave, assuming one can still build against it there, may well be a short-term answer.

Mojave requires Xcode 10 which contains only the 10.14 SDK.

MacPorts doesn't have any particular support at this time for accessing alternative SDKs that the user might have placed in other locations.

I worked on a port to standardize a way to provide other SDK versions, but I have not published it yet. MacPorts base changes would also be required to make it easy for ports to request SDKs that didn't come from the primary Xcode installation.

Post by Richard L. Hamilton
But IMO, this is still a good excuse to at least get STARTED on pushing everything toward x86_64, even if workarounds are still mostly possible; because in the next OS version, i386 will likely be gone or severely crippled.

Apple has announced that macOS 10.15 will remove all 32-bit support.

[Ian Wadham]

Post by Ryan Schmidt

Post by Richard L. Hamilton
So I think that the 10.13 SDK on Mojave, assuming one can still build against it there, may well be a short-term answer.

Mojave requires Xcode 10 which contains only the 10.14 SDK.
MacPorts doesn't have any particular support at this time for accessing alternative SDKs that the user might have placed in other locations.

I am on High Sierra 10.13.6, but the App Store app told me to upgrade to Xcode 10 and command line tools 10 (on 19 Sept 2018), so I did.

Now I am getting weird messages from ld when compiling and building some of my own C++ code which is based on KDE libraries obtained from Macports. Here is one example:

ld: warning: text-based stub file /System/Library/Frameworks//ApplicationServices.framework/Versions/A/ApplicationServices.tbd and library file /System/Library/Frameworks//ApplicationServices.framework/Versions/A/ApplicationServices are out of sync. Falling back to library file for linking.

There are other similar ones relating to CoreGraphics.framework, CoreText.framework, ImageIO.framework, CoreServices.framework and CFNetwork.framework.

Also I am getting loads of compiler warning messages about mismatched ‘struct’ and ‘class’ keyword usages and loads of undefined ld symbols re the classes and methods affected. So the whole build fails.

I had not edited, compiled or built that code since a few months ago.

Have I gone an Xcode version or a compiler version too far? If so, what should I do?

Cheers, Ian W.

Post by Ryan Schmidt
I worked on a port to standardize a way to provide other SDK versions, but I have not published it yet. MacPorts base changes would also be required to make it easy for ports to request SDKs that didn't come from the primary Xcode installation.

Post by Richard L. Hamilton
But IMO, this is still a good excuse to at least get STARTED on pushing everything toward x86_64, even if workarounds are still mostly possible; because in the next OS version, i386 will likely be gone or severely crippled.

Apple has announced that macOS 10.15 will remove all 32-bit support.

[Chris Jones]

Hi,

Post by Ian Wadham

Post by Ryan Schmidt

Post by Richard L. Hamilton
So I think that the 10.13 SDK on Mojave, assuming one can still build against it there, may well be a short-term answer.

Mojave requires Xcode 10 which contains only the 10.14 SDK.
MacPorts doesn't have any particular support at this time for accessing alternative SDKs that the user might have placed in other locations.

I am on High Sierra 10.13.6, but the App Store app told me to upgrade to Xcode 10 and command line tools 10 (on 19 Sept 2018), so I did.
ld: warning: text-based stub file /System/Library/Frameworks//ApplicationServices.framework/Versions/A/ApplicationServices.tbd and library file /System/Library/Frameworks//ApplicationServices.framework/Versions/A/ApplicationServices are out of sync. Falling back to library file for linking.
There are other similar ones relating to CoreGraphics.framework, CoreText.framework, ImageIO.framework, CoreServices.framework and CFNetwork.framework.
Also I am getting loads of compiler warning messages about mismatched ‘struct’ and ‘class’ keyword usages and loads of undefined ld symbols re the classes and methods affected. So the whole build fails.
I had not edited, compiled or built that code since a few months ago.
Have I gone an Xcode version or a compiler version too far? If so, what should I do?

I've updated and not had any such problems.

Have you installed / updated the command line tools for Xcode 10 ? They
should have come as an update on their own. Does clang give the ame
versions as below for you ?

Post by Ian Wadham
clang --version

Apple LLVM version 10.0.0 (clang-1000.11.45.2)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

Chris

Post by Ian Wadham
Cheers, Ian W.

Post by Ryan Schmidt
I worked on a port to standardize a way to provide other SDK versions, but I have not published it yet. MacPorts base changes would also be required to make it easy for ports to request SDKs that didn't come from the primary Xcode installation.

Post by Richard L. Hamilton
But IMO, this is still a good excuse to at least get STARTED on pushing everything toward x86_64, even if workarounds are still mostly possible; because in the next OS version, i386 will likely be gone or severely crippled.

Apple has announced that macOS 10.15 will remove all 32-bit support.

[Ian Wadham]

Post by Chris Jones

Post by Ian Wadham

Post by Ryan Schmidt

Post by Richard L. Hamilton
So I think that the 10.13 SDK on Mojave, assuming one can still build against it there, may well be a short-term answer.

Mojave requires Xcode 10 which contains only the 10.14 SDK.
MacPorts doesn't have any particular support at this time for accessing alternative SDKs that the user might have placed in other locations.

I am on High Sierra 10.13.6, but the App Store app told me to upgrade to Xcode 10 and command line tools 10 (on 19 Sept 2018), so I did.
ld: warning: text-based stub file /System/Library/Frameworks//ApplicationServices.framework/Versions/A/ApplicationServices.tbd and library file /System/Library/Frameworks//ApplicationServices.framework/Versions/A/ApplicationServices are out of sync. Falling back to library file for linking.
There are other similar ones relating to CoreGraphics.framework, CoreText.framework, ImageIO.framework, CoreServices.framework and CFNetwork.framework.
Also I am getting loads of compiler warning messages about mismatched ‘struct’ and ‘class’ keyword usages and loads of undefined ld symbols re the classes and methods affected. So the whole build fails.
I had not edited, compiled or built that code since a few months ago.
Have I gone an Xcode version or a compiler version too far? If so, what should I do?

I've updated and not had any such problems.
Have you installed / updated the command line tools for Xcode 10 ? They should have come as an update on their own. Does clang give the ame versions as below for you ?

Thanks very much for your reply, Chris.

I have Xcode and command line tools, both at v 10.0, updated on Wed 19 Sept 2018.

Post by Chris Jones

Post by Ian Wadham
clang --version

Apple LLVM version 10.0.0 (clang-1000.11.45.2)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

I get exactly the same output here for ‘clang —version’, also for ‘/usr/bin/clang’, which is what the CMake command in my build-script is using.

I shall dig further when I have some time.

Thanks again, Ian W.

Post by Chris Jones

Post by Ian Wadham

Post by Ryan Schmidt
I worked on a port to standardize a way to provide other SDK versions, but I have not published it yet. MacPorts base changes would also be required to make it easy for ports to request SDKs that didn't come from the primary Xcode installation.

Post by Richard L. Hamilton
But IMO, this is still a good excuse to at least get STARTED on pushing everything toward x86_64, even if workarounds are still mostly possible; because in the next OS version, i386 will likely be gone or severely crippled.

Apple has announced that macOS 10.15 will remove all 32-bit support.

[Ces VLC]

On Wed, Sep 19, 2018 at 7:54 PM Ryan Schmidt <***@macports.org>
wrote:
[...]

Post by Ryan Schmidt
Mojave requires Xcode 10 which contains only the 10.14 SDK.

Is it really required? Is it not possible to use Xcode 9.4.1 on Mojave?
(I'm asking because I thought Xcode had a requirement for the minimum MacOS
version it could run on, rather than the maximum MacOS version... obviously
with the limit of course that you cannot use new features from SDKs newer
than those provided with your Xcode version).

César

[Chris Jones]

Post by Ces VLC
[...]

Post by Ryan Schmidt
Mojave requires Xcode 10 which contains only the 10.14 SDK.

Is it really required? Is it not possible to use Xcode 9.4.1 on Mojave?
(I'm asking because I thought Xcode had a requirement for the minimum
MacOS version it could run on, rather than the maximum MacOS version...
obviously with the limit of course that you cannot use new features from
SDKs newer than those provided with your Xcode version).

As far as I am aware it is not possible, but even if it where its not a
solution, to require all macOS 10.13 users to stick with Xcode 9.

Chris

[Ces VLC]

On Thu, Sep 27, 2018 at 11:41 AM Chris Jones <***@hep.phy.cam.ac.uk>
wrote:
[...]

Post by Chris Jones
As far as I am aware it is not possible, but even if it where its not a
solution, to require all macOS 10.13 users to stick with Xcode 9.

Yes, it doesn't seem reasonable, but I admit I was asking this question not
just thinking in MacPorts, but also because I'd like to be able to continue
building 32bit code (not for deployment, but for internal testing: I build
and test code in both 32bit and 64bit, as a check that our code doesn't
make assumptions on the architecture word size). Apple, Apple, Apple...
with this attitude Macs will end up being used for final builds only (well,
I don't wish to go off-topic, we'll probably move development from
MacOS-native to encapsulated environments in VMs, --this will be the most
practical solution, putting feelings and likes/dislikes aside).

Anyway, copying the 10.13 SDK into Xcode 10 should work, but I was feeling
curious on why Xcode 9.4.1 won't work on Mojave.

César

[Richard L. Hamilton]

Clearly you can install 9.4.1 on Mojave...and it seems to work at least for trivial code, even compiling to 32 bit:

sh-3.2$ uname -a
Darwin bigapple-mojave.pri 18.0.0 Darwin Kernel Version 18.0.0: Wed Aug 22 20:13:40 PDT 2018; root:xnu-4903.201.2~1/RELEASE_X86_64 x86_64
sh-3.2$ xcode-select --print-path
/Applications/Xcode_9.4.1.app/Contents/Developer
sh-3.2$ cat hello.c
#include <stdio.h>
int
main(int argc, char **argv)
{
(void) printf("Hello, world!\n");
return (0);
}
sh-3.2$ gcc -m32 hello.c -o hello
sh-3.2$ file hello
hello: Mach-O executable i386
sh-3.2$ ./hello
Hello, world!

I have both installed, and simply switched the command line instances with
sudo xcode-select --switch /Applications/Xcode_9.4.1.app/Contents/Developer
I could switch back with
sudo xcode-select --switch /Applications/Xcode.app/Contents/Developer

The sample is a very undemanding C program. Not sure how well it would work with C++, or Objective C, esp. if it was pushing the limits of what a 32-bit executable was allowed to do on the prior OS release. And I hadn't been able to figure out how to do a 32-bit build with the GUI, although since I rarely use it, that could well be me, not it.

[...]

Post by Ryan Schmidt
Mojave requires Xcode 10 which contains only the 10.14 SDK.

Is it really required? Is it not possible to use Xcode 9.4.1 on Mojave? (I'm asking because I thought Xcode had a requirement for the minimum MacOS version it could run on, rather than the maximum MacOS version... obviously with the limit of course that you cannot use new features from SDKs newer than those provided with your Xcode version).
César

[Ces VLC]

Post by Richard L. Hamilton
Clearly you can install 9.4.1 on Mojave...and it seems to work at least

for trivial code, even compiling to 32 bit:
[...]

Post by Richard L. Hamilton
I have both installed, and simply switched the command line instances with
[...]

Thanks! I didn't consider installing both, but it could be a nice idea!
Thanks!

César

[Dominik Reichardt]

At least for command line building of things this will be a way to keep old xxode around.

[...]

Post by Richard L. Hamilton
I have both installed, and simply switched the command line instances with
[...]

Thanks! I didn't consider installing both, but it could be a nice idea! Thanks!
César

[Ces VLC]

Post by Dominik Reichardt
At least for command line building of things this will be a way to keep old xxode around.

Well, on second thought, if you want to generate 32bit executables with the
newest compilers, it should be possible to build LLVM 7.0 and use it with
the MacOS 10.13 SDK. So, no need to be limited to older compiler versions.
And I think that's in fact what I'm going to do in Mojave.

César

[Ken Cunningham]

Mojave requires Xcode 10 which contains only the 10.14 SDK. MacPorts doesn't have any particular support at this time for accessing alternative SDKs that the user might have placed in other locations.

I've been forcing MacPorts to do "bad" things for years, building stuff on 10.6.8 that has no rightful place being built there.

This bit of Josh's in libsdl2 works just fine to force a build against the 10.7 SDK on 10.6.8, for example.

platform macosx {
if {${os.major} <= 10} {
# Build requires at least 10.7.3 SDK, even when targeting 10.6
set lion_sdkpath ${developer_dir}/SDKs/MacOSX10.7.sdk
if {[file exists $lion_sdkpath]} {
configure.sdkroot $lion_sdkpath
} else {
pre-fetch {
error "Building $name @${version} on Mac OS X 10.6 requires the MacOSX10.7.sdk to be present in ${developer_dir}/SDKs/"
}
}
}
}


The Xcode clang in /usr/bin/ will complain that it can't build against libc++ on 10.6.8, but any macports-clang will do so very happily.

It seems most stuff can be forced to build against any SDK you want, most of the time. I build TenFourFox against the MacOSX.10.4u.SDK on 10.6.8 using gcc4.8 without any troubles.

It gets tricky when it's an xcodebuild Port, but there I just symlink in the macports-clang instead of the xcode clang into the SDK, and the macports-clang happily does what you want it to, building against libc++ on 10.6.8 or what have you.


SO - without having tried it -- setting

configure.sdkroot /path/to/10.13.SDK

and building with any non-Xcode clang might have at least some chance of working to build i386 software.


Ken

[Thomas Bodlien]

Post by Ces VLC
Well, on second thought, if you want to generate 32bit executables with the
newest compilers, it should be possible to build LLVM 7.0 and use it with
the MacOS 10.13 SDK. So, no need to be limited to older compiler versions.
And I think that's in fact what I'm going to do in Mojave.
César

But why?
What do you need 32-Bit Support for?

[Ces VLC]

El El vie, 28 sept 2018 a las 18:50, Thomas Bodlien <

Post by Thomas Bodlien
But why?
What do you need 32-Bit Support for?

I said it in a previous message: for testing purposes and code quality
verification (yes, I can use a 32bit Linux VM for that, but I prefer to
keep MacOS as primary development platform for a bit more, although it
seems it’s time to “put the wheels in motion”).

César

[Dominik Reichardt]

Post by Thomas Bodlien

Post by Ces VLC
Well, on second thought, if you want to generate 32bit executables with the
newest compilers, it should be possible to build LLVM 7.0 and use it with
the MacOS 10.13 SDK. So, no need to be limited to older compiler versions.
And I think that's in fact what I'm going to do in Mojave.
César

But why?
What do you need 32-Bit Support for?

Performance? For example DOSBox is three times faster in 32bit ;)

But in general, these questions are pointless. Some years ago the question was "what do you need 64bit support for" when peoole asked for it...

[Michael]

Post by Thomas Bodlien
But why?
What do you need 32-Bit Support for?

Wine is probably the best example of a 32 bit only port right now.

---
Entertaining minecraft videos
http://YouTube.com/keybounce

[Ryan Schmidt]

Post by Michael

Post by Thomas Bodlien
But why?
What do you need 32-Bit Support for?

Wine is probably the best example of a 32 bit only port right now.

Wine isn't 32-bit only; it's universal. And with a few changes to the Portfile it can build 64-bit only. But then it can't run any 32-bit Windows software, which is probably rather limiting. As I mentioned in other threads, I'm working on a solution involving the use of the 10.13 SDK on 10.14 so that we can continue to build universal, and Codeweavers is working on a solution that will work even after macOS drops 32-bit support entirely, probably through the use of an emulator like qemu.

[William H. Magill via macports-users]

Post by Ryan Schmidt

Post by Michael

Post by Thomas Bodlien
But why?
What do you need 32-Bit Support for?

Wine is probably the best example of a 32 bit only port right now.

Wine isn't 32-bit only; it's universal. And with a few changes to the Portfile it can build 64-bit only. But then it can't run any 32-bit Windows software, which is probably rather limiting. As I mentioned in other threads, I'm working on a solution involving the use of the 10.13 SDK on 10.14 so that we can continue to build universal, and Codeweavers is working on a solution that will work even after macOS drops 32-bit support entirely, probably through the use of an emulator like qemu.

LOL - So much for the “explanation” — Wine Is Not An Emulator :)

T.T.F.N.
William H. Magill
# iMac11,3 Core i7 [2.93GHz - 8 GB 1067MHz] OS X 10.13.6
# Macmini6,1 Intel Core i5 [2.5 Ghz - 4GB 1600MHz] OS X 10.13.6
# MacPro5,1 Quad-Core Intel Xeon [2.8 GHz - 16 GB 1066 MHz] OSX 10.13.6
***@icloud.com
***@mac.com
***@gmail.com