Closed totaam closed 3 years ago
Ah. That's because the 4.0 builds are supposed to require 10.14 or later IIRC, but I forgot to bump the LSMinimumSystemVersion, which would have given you a nice warning message instead of failing with symbol errors.
The question now is, do I:
I think I will attempt (2) after making a backup. This is going to take time..
Rebuilt everything with min_sdk=10.12
, and updated the manifest so we require 10.12: r25762.
There's a new build (just without the manifest change) in the beta area.
Tested OK on a 10.12.x VM.
BTW, there are 4.0 builds in the beta area which I have built using the "old" 10.11.x VM which is normally used for making 3.0.x LTS builds. Those also work. (ie: the 25756 builds does work IIRC)
Note to self: I shouldn't do that, as it could be confusing if one version exhibits a problem and another doesn't - this is not necessarily a code change - could just be a library change / build env bug.
Handy for those, like me, that are paranoid about Mac changing library structures... looks like Xpra-Python3-x86_64-4.0-r25761.dmg does indeed work with a 4.0-25719 Fedora 30 server.
I also double checked, works against the 3.0.7-25627 server I get from the stable repo also.
So, guess I'll close this and say thanks.
The new builds were crashing in the opengl probing code (looked like memory corruption), so I had to revert r25801 and r25762: r25853.
I even tried rebuilding everything, from scratch. Twice.
v4 will require 10.14 or later. Sorry. At least now the OS will give a better warning message rather than an error.
I refused to let this go because I want the new build VM (#2505) to be reliable, and rebuilding everything from scratch does reproduce the bug. Almost a full day later, the problem comes from r25775 (gtk bumped from 3.24.10 to 3.24.14) now reverted in r25870. So in theory, we could still allow 10.12+ and make it work..
Issue migrated from trac ticket # 2672
component: client | priority: major | resolution: fixed
2020-03-23 22:11:31: afarr created the issue