User information about macOS Mojave

Wed Sep 19 16:54:50 UTC 2018

> On Sep 19, 2018, at 11:49, Julien Salort <listes at salort.eu> wrote:
> 
> Le 19/09/2018 à 17:12, Ken Cunningham a écrit :
> 
>> 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 874 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.macports.org/pipermail/macports-users/attachments/20180919/3a82e488/attachment.sig>