Min version macOS

Hello,

Since 2.4.0 is out the 2.4.0-rc-20210111 files are not available any more. Now the macOS native libraries are fat x86_64/arm64 binaries and the minimum macOS version is 11.0 (and 11.3 SDK has been used). In rc-20210111 we had

      cmd LC_VERSION_MIN_MACOSX
  cmdsize 16
  version 10.5
      sdk 10.11

and as a result the natives cannot be used on older macOS versions (they work on Catalina 10.15 but fail for previous versions). Was it possible to use a lower macOS deployment target in the build of macOS natives of 2.4.0 ?

Are the 2.4.0-rc-20210111 files available somewhere ?

S.

Hello,

I don't want to throw away my old MacBook Pro that I can't upgrade to Catalina and would prefer not to force people to jump to macOS 11.
Therefore, I just tried to rebuild Gluegen and JOGL after replacing

mmacosx-version-min=11.0

by

mmacosx-version-min=10.5

in gluegen/make/gluegen-cpptasks-base.xml

Gluegen was built without issues but the linker refused to build JOGL because of the following error

Undefined symbols for architecture x86_64: 
  "__Unwind_Resume",referenced from:
      _updateContextRegister in MacOSXWindowSystemInterface.o

which comes from the new call to dispatch_sync in the function updateContextRegister of MacOSXWindowSystemInterface.m programmed in this commit.

Maybe someone here knows how to replace dispatch_sync by something which would perform the same thing? Or maybe call it by reflection if it's necessary in recent macOS versions?

mottelet wrote

Are the 2.4.0-rc-20210111 files available somewhere ?

The version 2.4.0-rc-20210111 of gluegen-rt.jar, jogl-all.jar and gluegen / jogl DLLs built for Windows, Linux and macOS x86_64/arm64 are available at:
https://sourceforge.net/p/sweethome3d/code/HEAD/tree/tags/V_7_0_2/SweetHome3D/lib/java3d-1.6/
and the version 2.4.0-rc-20221118 of jogall.jar file which fixes a hanging issue under macOS explained here is available in:
https://www.sweethome3d.com/downloads/jogl-all-2.4.0-rc-20221118.zip

Stephane, Emmanuel, I will look into this in a few days - earmarked.

I chose the 11 SDK to have the aarch64 being build on a 'current XCode' release.
I do have the old SDK folders, however - as far as I remember -
the aarch64 was not available on 10.5, or am I wrong?

If you know a good SDK version covering all MacOS targets, tell me.

The dispatch_sync can be replaced, I was just looking for an easier way
how to inject a 'runnable' into main-thread using this new Objective-C lambda equivalent :)

Thanks for trying to make it work on more macOS versions and happy to learn that dispatch_sync can be replaced.

You can build the .dylib files under Catalina 10.15 with XCode ("gcc --version" returns "12.0.0").
I tried yesterday and it (almost) worked, leading to fat .dylib files.

An other important thing I noticed yesterday: to ensure that libjawt.dylib is compatible with the targeted OS, build JOGL with JDK 11 (it won't work with JDK 15).

Do you exactly know why it won't work with OpenJDK 15?

Sorry, my last comment was wrong. I forgot to create the fat version of libjawt.dylib in JDK 15 with lipo, the reason why the linker couldn't work. I tried again with an updated libjawt.dylib and it worked this time.
Just remains dispatch_sync to be replaced.

Manu wrote

Sorry, my last comment was wrong. I forgot to create the fat version of libjawt.dylib in JDK 15 with lipo, the reason why the linker couldn't work. I tried again with an updated libjawt.dylib and it worked this time.
Just remains dispatch_sync to be replaced.

Right, I was building from OpenJDK17 (that other free build).
Will see if my newer XCode allows this path ..

Manu wrote

I don't want to throw away my old MacBook Pro that I can't upgrade to Catalina and would prefer not to force people to jump to macOS 11.

By the way, I don't tell people to throw away "old" computers that still work but maintaining backward compatibility can be very challenging in some cases (and time consuming too), especially under OS X. In my humble opinion, avoiding to make any confusion between software and hardware limitations is important, preventing old MacBook Pros from upgrading to Catalina is Apple's decision and when maintaining backward compatibility in a particular case becomes impossible, Apple will be to blame, not the JogAmp community. The end users can still install another operating system that doesn't embrace planned obsolescence or use a virtual machine (VirtualBox, etc) to avoid throwing away old MacBook Pros, it's a matter of choice, you can't have the cake and eat it, Apple hardware isn't designed to last.

Right Julien, I will also give this only one shot when preparing the next release.
This is similar to older Windows versions _and_ support for 32bit machines - as obsoleted by Microsoft.

On my older MacBook I installed Debian 11 and it worked out of the box, squashed MacOS.

Bottom line, its the vendors choice...

Yes and as far as I remember, Adoptium (previously AdoptOpenJDK) has never provided 32-bit JREs and Oracle provides 32-bit JREs only for Java 8 but with a restrictive license, which makes things hard to test even though you have the right very old hardware. My computers were assembled between 2007 and 2012, none have 32-bit microprocessors, I have been unable to test 32-bit JREs for years. In my humble opinion, allowing people to build JogAmp to target 32-bit machines is a good compromise and when keeping backward compatibility doesn't require a disproportionate effort compared to the targeted audience, I'm all for it. It allows to take into account particular situations, typically when a software has a large audience still using this kind of combination of hardware and operating system.

I don't think it's up to us to decide whether people should continue to use a 32 bit system or not.
I can't tell how many people still use Sweet Home 3D under Windows 32 bit, but its Linux 32 bit version still shows a not negligible download count (185 per week).
Anyway, thanks for keeping the options to build JOGL 32 bit if we want to.

About replacing dispatch_sync call in macOS, I found this discussion which  suggests to use performSelectorOnMainThread but I don't know how I can check such a change is working.

Manu wrote

I don't think it's up to us to decide whether people should continue to use a 32 bit system or not.

Manu, we are just talking about the vendor of these OS who are ending support for mentioned hardware,
namely Microsoft and Apple - not us.
We are not prohibiting anything, I doubt JogAmp is that crucial - I would wish though :)

In regards to JogAmp supporting platforms and users,
my question _now_ is how my (and others, dreaming on) work on JogAmp can be supported to please the aforementioned.
If our work would be supported anything would go.

In the last months, a maximum pain moment has been reached regarding one platform (Apple's Aarch64 M1).
This resulted in one tiny contract for us.

Since this gave us some attention back, I revamped my ideas to give our dear project and the UI vision
another chance b/c I value it a lot (-> Graph UI, video etc).

Traffic on the servers got a lot of traction and I have thankfully received gestures of
JogAmp is too important to die, however, all of this didn't result in actual contracts or funding support yet.

If there is no sustainable feedback my JogAmp work will fall back to maintenance levels from my behalf.

To be fair, I also failed to be successful for related or unrelated general contractual work sadly
and am aware of the current and ever rising world crisis.
I am surely not alone in this task these days, i.e. trying to survive this period.
Hence I will stay patient and see what will happen, pressing both thumbs for all of us.

I also have to admit that my networking and selling skills are very limited,
hence everybody is more than welcome to help in this regard connecting with the right parties.
(This related either to JogAmp or other work)

Sorry for the late answer.

This is not the problem of the SDK but rather the macOS deployment target. For x86_64(Intel) you can build with macOS 11 SDK and precise MACOSX_DEPLOYMENT_TARGET=10.9. For aarch64 the deployment target cannot be lower that 11.

S.

I ran:

export MACOSX_DEPLOYMENT_TARGET=10.9

before launching Ant but it didn't create .dylibs able to work with Mac OS X 10.9.

Then, in jogl/src/jogl/native/macosx/MacOSXWindowSystemInterface.m, I replaced:

dispatch_sync(dispatch_get_main_queue(), ^{
      contextUpdater = [[ContextUpdater alloc] initWithContext: ctx view: view];

by the call:

void * params [] = {&contextUpdater, ctx, view};
[ctx performSelectorOnMainThread:@selector(setContext) withObject:params waitUntilDone:YES];

and added this declaration (updated on April 13):

void setContext(void ** params) { // [ContextUpdater** contextUpdater, NSOpenGLContext* ctx, NSView* view]
  *((ContextUpdater **)params [0]) = [[ContextUpdater alloc] initWithContext: params [1] view: params [2]];
}

I know it's an ugly patch and there must be a cleaner way to achieve the same thing, but I'm not an Objective C expert and performSelectorOnMainThread doesn't seem to accept a selector with 3 parameters.
This change compiled with -mmacosx-version-min=10.5 flag set in gluegen/make/gluegen-cpptasks-base.xml, and the generated .dylibs worked under Mac OS X 10.9 and macOS 13.3, but I don't know how to prove that calling setContext works correctly.

Yup, Manu .. that is the change for old MacOS, something like this.
I did use the new lambda for passing args more flexible - just sugar coating.

Real beast is, we won't have the fat libs generated with 10.9 for aarch64,
so may need to either do it manually in the process or 'just' provide two libs.
That is OK.

If all goes well, I shall have time to do this next weeks including a final hacking on HiDPI :)
Pressing both thumbs.

In the meantime, I push Graph + GraphUI forward etc.

On my side, I had no problem to generate directly fat libraries, by running Ant under macOS 10.15.

Manu wrote

On my side, I had no problem to generate directly fat libraries, by running Ant under macOS 10.15.

Hmm ;-)

that is b/c you use

Manu wrote

Catalina 10.15 with XCode ("gcc --version" returns "12.0.0").

I will try to adjust here in the coming days, hopefully :)

Surely would help downgrading the XCode to please them all until ..,
so maybe a longer term solution is to just have to libs?
Apple always gives us something to do I guess :)

One way or the other .. will be done.

Sven Gothel wrote

maybe a longer term solution is to just have two libs?

Or build fat ones aftwards with lipo. This can be done from Ant without problem (I used lipo to build a universal OpenJDK for Sweet Home 3D) but it will require some bigger changes in build.xml than using gcc 12.0.0.

yup, I used that to produce the JVM fat libs via lipo .. injected to the build machine.

Thank you.