External libraries on Apple OS/X systems.

[modelica-trac-importer]

Reported by stefanv on 5 Jan 2018 19:07 UTC Section 12.9.4 of the Modelica Specification lists several platform names to be used as directory names for libraries. Missing from these are names for Apple OS/X based systems. My colleague has suggested using "darwin64" as has been adopted by FMI (and I presume "darwin32" for older OS/X machines).

---

Migrated-From: https://trac.modelica.org/Modelica/ticket/2220

[modelica-trac-importer]

Comment by sjoelund.se on 6 Jan 2018 07:55 UTC So is that a 64-bit PPC, x86, or ARM CPU for Apple's OSes? See also fmi:#302

[modelica-trac-importer]

Comment by hansolsson on 22 Mar 2018 13:50 UTC Language group: Can introduce darwin32/darwin64 for intel-based OS/X, but for the rest rely on future decision for FMI so that we are compatible.

[modelica-trac-importer]

Modified by beutlich on 23 Mar 2018 08:05 UTC

[beutlich]

Cross reference: https://github.com/modelica/fmi-standard/issues/302

[HansOlsson]

Since we haven't added this yet and FMI seems to have changed compared to the original posts (using x86_64-darwin instead of darwin64) it seems that we should revisit this.

[HansOlsson]

Fixing labels to have better overview.

[HansOlsson]

Since FMI is (as noted) different and Apple have changed architecture (again) we should likely revisit this.

[eshmoylova]

Can we revisit it soon? The new Apple architecture is more common. For what FMI has at the moment see 2.5.1.4.1 Platform Tuple Definition in https://fmi-standard.org/docs/3.0-dev/#structure-of-zip (@maplesoft-fmigroup)

[otronarp]

When (if?) this is revisted, one could also consider to standardize a location for universal macOS binaries (which doesn't seem to be defined for FMI 3).

[HansOlsson]

To me "universal binaries" and directories for different architectures are two different solutions for the same problem, and I'm not sure if we need to mix them.

A work-around is to put the same "universal binary" in multiple directories (ideally using a file system link) - or lipo -extract... them.

The FMI-3 is now: https://fmi-standard.org/docs/3.0/#structure-of-zip

I see two proposals:

• darwin64 for Apple on X86-64
• allow the FMI 3 names as an alternative to the previous names. Specifically, allow them but say that only one can be used for each directory and architecture, and neither is deprecated.

[HansOlsson]

• allow the FMI 3 names as an alternative to the previous names. Specifically, allow them but say that only one can be used for each directory and architecture, and neither is deprecated.

And ignore the current example of ABI for FMI 3 (as that compiler version cannot (easily) be automatically extracted, and Visual Studio compilers are more ABI-stable than it suggests) and hope that FMI gets a better alternative.

[Maplesoft-fmigroup]

We're fine with using aarch64-darwin for ARM64 Macs (and darwin64 for Intel Macs) for now but the proposal to support both naming schemes is a bit messy. Are we going to accumulate more possibilities as new naming schemes are introduced in the future? It would be cleaner to standardize this to a single scheme now.

[HansOlsson]

Web-meeting: Ask for additional comments.

[sjoelund]

Looking at FMI3 closer, it seems fine and much nicer than FMI2. But aarch32 is a little weird since there are so many different incompatible instruction sets (arm6, arm7h, arm7l; is it hardfloat or softfloat, etc). Note that some Raspberry Pi models only support armv6 instructions and it's not like x86 extensions where you can have different instructions in the same executable; it's a totally different instruction set... We could just gloss over it and say aarch32 like FMI3 since you are likely running FMUs on such systems and not the full Modelica tool anyway.