Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
forrcaho opened this issue Jan 8, 2022 · 7 comments
Open

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

forrcaho opened this issue Jan 8, 2022 · 7 comments
Labels

Comments

@forrcaho
Copy link

forrcaho commented Jan 8, 2022

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
Copy link
Member

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
Copy link
Member

x42 commented Jan 8, 2022

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
Copy link
Member

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
Copy link
Member

x42 commented Jan 8, 2022

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
Copy link
Member

x42 commented Jan 8, 2022

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
Copy link
Author

forrcaho commented Jan 8, 2022

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
Copy link
Member

x42 commented Jan 28, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants