search

zynaddsubfx / zyn-build-osx

OSX build script for zynaddsubfx
13 stars 7 forks source link

Should the versions in 00_gcc7.sh be updated? #6

Open forrcaho opened 2 years ago

forrcaho commented 2 years ago

One of the tarballs referenced in 00_gcc7.sh has moved:

http://www.mpfr.org/mpfr-4.0.0/mpfr-4.0.0.tar.bz2 needs the protocol changed to https, or else the -L switch added to the curl command so it follows the redirect.

I would have submitted a simple PR, but I couldn't help noticing how old the versions are that get downloaded. The latest gcc appears to be 11.2 now, for instance. Is there a known reason not to change this script to get the latest tarballs?

fundamental commented 2 years ago

I'll accept the mpfr no problem. Per the gcc version, it was I think originally chosen in part due to how gcc versions impacted ABI compatibility with some system libraries. Though I could be mistaken on that point and building gcc simply allowed us to compile on an older MacOS system to establish compatibility with that system release and later releases. I'm not great with MacOS myself, so others might be able to add in a better correction.

x42 commented 2 years ago

Now that there is macOS 11, OSX is mostly dead, PPC and 32bit Intel are near irrelevant.

It may be time to drop this project, and instead build directly with clang, also focusing on a M1/ARM build.

fundamental commented 2 years ago

How hellish is the signing process which would appear on the newer systems? I know wrl has talked about those pains quite a lot and up to now we've been avoiding them.

x42 commented 2 years ago

it was I think originally chosen in part due to how gcc versions impacted ABI compatibility with some system libraries.

The motivation for this was to allow C++11 but still produce binaries that run on OSX 10.5 ... 10.9. With Apple's default toolchain, C++11 binaries required libc++, which is only available starting 10.9 and/or 10.11

x42 commented 2 years ago

How hellish is the signing process which would appear on the newer systems?

It is less of a technical and only a political and ethical issue.

Local builds are not affected, when distributing software you can point users to https://disable-gatekeeper.github.io/ Bundling the plugin in a .pkg instead of .dmg also allows to sidestep some of this.

forrcaho commented 2 years ago

I'm running Catalina (10.15.7) and am hesitant to upgrade because I primarily use my mac for work, and ever since Catalina, OS X upgrades tend to break important things like VPN clients.

Do I still need to use gcc 7? I don't want to try building a later gcc with static linking if it's known not to work.

x42 commented 2 years ago

The main use of this repo was to create a distributable version of the plugin that works from OSX 10.6 onwards. gcc was needed because it can provide a libstdc++ with C++11 support that works on OSX and older macOS systems.

If you use Apple's clang and Apple's libc++that will limit the resulting binary to work on 10.10 or 10.11 and newer only.

PS. If you compile a local version for your own needs, you do not need to use this repo at all.