forcing 10.12 or 10.13 builds onto 10.14 for 32bit fix?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

forcing 10.12 or 10.13 builds onto 10.14 for 32bit fix?

Ken Cunningham
I notice homebrew is forcing the installation of binaries built on their 10.12 or 10.13 builders onto 10.14 to get around the 32bit build problem on 10.14.

I don't believe there is any way to force our binary installer to install older system builds in the same way -- but if there was, it would grant us a reprieve for a year for the 32bit issue.

So I thought I'd ask if anyone can imagine how this might be done.

Ken
Reply | Threaded
Open this post in threaded view
|

Re: forcing 10.12 or 10.13 builds onto 10.14 for 32bit fix?

Ryan Schmidt-24


On Oct 29, 2018, at 01:15, Ken Cunningham wrote:

> I notice homebrew is forcing the installation of binaries built on their 10.12 or 10.13 builders onto 10.14 to get around the 32bit build problem on 10.14.
>
> I don't believe there is any way to force our binary installer to install older system builds in the same way -- but if there was, it would grant us a reprieve for a year for the 32bit issue.
>
> So I thought I'd ask if anyone can imagine how this might be done.

At the moment, you're right, we don't have anything that can do that. So at the moment we would need to find a way to compile 32-bit on 10.14. Jack Howarth mentioned that the system dylib still has 32-bit symbols (of course, so that it can run 32-bit software) but that the tbd file for the system library doesn't have the 32-bit symbols anymore, which is what causes the build failure, and that there is a way to force the build to look at the dylib instead of at the tbd, but he didn't elaborate about how that would be accomplished. If we can figure that out, that might be the answer.

As for the method you suggested, it's part of a larger problem. More and more we are encountering ports that can run on earlier systems but only if they are built on newer systems -- this seems to match what Apple wants their developers to do (use the latest OS, Xcode, SDK, and use an earlier deployment target to offer the app to older systems) -- and therefore we can't at present offer them to those older systems in MacPorts. It might be good if we could specify for those ports that they should have an older deployment target, and that older systems should download the binary built on the newer system. I haven't given much thought yet to what kind of portfile syntax we might want to use to convey that. It also wouldn't help users who build from source, which would include nondistributable ports, so it still seems like focusing on being able to build a port on the OS version where we want to use it, as we have always done, is still what we should be doing.

Reply | Threaded
Open this post in threaded view
|

Re: forcing 10.12 or 10.13 builds onto 10.14 for 32bit fix?

Christopher Jones


> At the moment, you're right, we don't have anything that can do that. So at the moment we would need to find a way to compile 32-bit on 10.14. Jack Howarth mentioned that the system dylib still has 32-bit symbols (of course, so that it can run 32-bit software) but that the tbd file for the system library doesn't have the 32-bit symbols anymore, which is what causes the build failure, and that there is a way to force the build to look at the dylib instead of at the tbd, but he didn't elaborate about how that would be accomplished. If we can figure that out, that might be the answer.

If I may be frank, to me this is all just an exercise in delaying the
inevitable. 32bit builds days are number, and jumping through hoops to
keep it going, for a year or so until the runtime is completely removed,
seems effort spent in the wrong direction.

Other than wine, which I am aware of, which other ports currently do not
build 64bit ?

Chris
Reply | Threaded
Open this post in threaded view
|

Re: forcing 10.12 or 10.13 builds onto 10.14 for 32bit fix?

Mojca Miklavec-2
In reply to this post by Ken Cunningham
On Mon, 29 Oct 2018 at 07:15, Ken Cunningham wrote:
>
> I notice homebrew is forcing the installation of binaries built on their 10.12 or 10.13 builders onto 10.14 to get around the 32bit build problem on 10.14.
>
> I don't believe there is any way to force our binary installer to install older system builds in the same way -- but if there was, it would grant us a reprieve for a year for the 32bit issue.
>
> So I thought I'd ask if anyone can imagine how this might be done.

I really like Ryan's approach:
    https://github.com/ryandesign/macports-ports/blob/MacOSX.sdk/devel/MacOSX.sdk/Portfile
    https://github.com/ryandesign/macports-base/commits/MacOSX.sdk

... as long as this makes it into MacPorts FAST. If we keep delaying
these changes for two more years, they will no longer make any sense.

That said, I would like it if MacPorts had somewhat better support for
compiling binaries targeting older OSes on newer ones, ... and if we
occasionally allowed fetching binaries meant for an older system to a
newer one. In case of Wine this is a can of worms to some extent since
wine has a huge dependency list, and all of those would need to come
from 10.13. If it was just wine itself, it would be an easier task.

I don't know how HB is doing it, but they could easily afford to
install multiple libraries in parallel, and only use the ("hidden")
32-bit library built on 10.13 of X for Wine, while keeping using the
64-bit library built on 10.14 for everything else.

Mojca
Reply | Threaded
Open this post in threaded view
|

Re: forcing 10.12 or 10.13 builds onto 10.14 for 32bit fix?

Joshua Root-8
On 2018-10-30 06:13 , Mojca Miklavec wrote:
> That said, I would like it if MacPorts had somewhat better support for
> compiling binaries targeting older OSes on newer ones, ...

Unfortunately it's mostly not MacPorts that needs the support but the
individual build systems, most of which have no concept of macOS weak
linking. How many ports would need to be manually patched to not use
utimensat when targeting 10.12, as just one example?

- Josh
Reply | Threaded
Open this post in threaded view
|

Re: forcing 10.12 or 10.13 builds onto 10.14 for 32bit fix?

Mojca Miklavec-2
On Mon, 29 Oct 2018 at 21:43, Joshua Root wrote:
> On 2018-10-30 06:13 , Mojca Miklavec wrote:
> > That said, I would like it if MacPorts had somewhat better support for
> > compiling binaries targeting older OSes on newer ones, ...
>
> Unfortunately it's mostly not MacPorts that needs the support but the
> individual build systems, most of which have no concept of macOS weak
> linking. How many ports would need to be manually patched to not use
> utimensat when targeting 10.12, as just one example?

There are two possibilities:
- weak linking
- actually linking against an older SDK

Proper support for the first option would be next to mission
impossible (for anything but [Objective C] programs which have been
written with macOS in mind). Support for the second group is totally
feasible, but MacPorts doesn't even consider this at the moment.
Portfiles use something like "if this is darwin X, then do Y", but in
many cases one would need this condition to depend on the target OS
rather than on the OS where the software is being compiled.

(Anyway, I would not consider this such a high priority to do. Simply
getting Wine and alike to work by any other means sounds more
interesting and important, but even upstream developers will need to
do something soon anyway.)

Mojca