Also used existing `CFLAGS` and `LDFLAGS` environment variable values,
so a user can easily set these when running the build script to add more
paths. Previously they were set to explicit values ignoring any existing
value.
This might help resolve issues where libgccjit.h is not found as
reported in issue #20. Though I have not been able to reproduce this
myself, it seems adding the libgccjit's include dir has solved the issue
for some.
The old patch would dynamically glob within
Emacs.app/Contents/MacOS/lib/gcc using the full absolute path to
Emacs.app. If there are obsure characters like "[]" and others in the
absolute path, it can cause glob search within the
native-compile-setup-environment-variables function to fail, in turn
preventing native-comp from working.
The fix is to hard-code the relative paths from Emacs'
invocation-directory (**/Emacs.app/Contents/MacOS) into the environment
setup function itself, making it very simple and effectively just
joining a few strings and setting an environment variable.
It did require a little bit of cleanup and better organization of the
GCC/libgccjit releated code in the build script, creating a new GccInfo
class which is the central place for determining various paths and
information about GCC and libgccjit which the build will be using.
The underlying patching code was removed in v0.4.1 (commit
70bf6b05d5), as it was no longer needed,
but the related CLI flag and README info was mistakenly left in place.
On a fresh install of Big Sur with only the Xcode CLI tools installed,
autoconf is not available. Hence it needs to be installed from homebrew
instead.
The new libgccjit Homebrew formula negates the need to install a custom
patched gcc formula from source to get libgccjit.
As it's a separate formula, the file structure is a bit different
though, requiring some changes to the script. This means it is no longer
compatible libgccjit from the custom gcc formula. If you already have
the custom patched gcc formula installed, you can replace it with the
standard gcc formula by running:
brew reinstall gcc
In theory though, it should work even with the patched gcc formula, as
long as libgccjit is installed too. But it will probably produce a
Emacs.app that's around 35MB larger than it needs to, thanks to
duplicating the libgccjit.so.0.0.1 file within the final application.
BREAKING CHANGE: Standard Homewbrew `gcc` and `libgccjit` formula are now required for native-comp, instead of the custom patched gcc formula.
Recent builds seem to pre-allocate empty `*.eln.tmp` files rather than
empty `*.eln` files. So the issue of empty `*.eln` files preventing
Emacs from starting should no longer be an issue.
I'm leaving #3 open for now, in case anyone is using older git SHAs from
the list of known good commits in #6.
Replace the launcher script with a emacs-lisp patch to `comp.el` which
sets the `LIBRARY_PATH` environment variable to point at the embedded
GCC/libgccjit.
This fixes issues related to the launcher script on macOS 10.15 and
later.
Fixes#14
BREAKING CHANGE: `--[no-]launcher` option is deprecated, as launcher script is no longer used.
The feature/native-comp branch no longer supports the use of the
NATIVE_FAST_BOOT environment variable. It has been replaced by
NATIVE_FULL_AOT (Ahead of Time compilation).
As the new environment variable's value is opposite of the old one, it
is disabled by default.
Under the hood, the --[no-]native-full-aot option still sets the
NATIVE_FAST_BOOT environment variable as needed to ensure it works as
expected when producing builds against older commits, and also newer
ones.
BREAKING CHANGE: Deprecate `--[no-]native-fast-boot` option in favor of `--[no-]native-full-aot`
Turns out that `sw_vers -productVersion` doesn't always return a version
string with a `MAJOR.MINOR.PATCH` format, but can also just return two
digits, like `11.0` on the current beta of macOS Big Sur.
Fixes: #13
When SVG support is enabled via librsvg, launching builds of Emacs 27.1
or later from the Finder into GUI mode will crash Emacs if the fancy
startup screen is used. This crash has been observed with librsvg
2.46.4, 2.48.7 and 2.48.8.
Hence SVG image support is now disabled by default. Should you need it,
you will need to disable the startup screen to avoid Emacs crashing, by
putting this in your init.el:
(setq inhibit-startup-screen t)
The cause of the issue seems to be the `image-size` function as called
from `use-fancy-splash-screens-p`.
The solution to get libgccjit properly working, and embedded in
Emacs.app included:
- The contents of GCC's lib folder (`/usr/local/opt/gcc/lib`) is copied
into the `Contents/MacOS/lib-<arch>-<os_version>` folder.
- Setting `LIBRARY_PATH` environment variable to correct GCC lib
folders within Emacs.app. This is done through a bash launcher script
which replaces the regular `Contents/MacOS/Emacs` executable. The main
Emacs executable itself is named `Emacs-bin` now instead, so anything
that depends on the exact process name will need updating.
- The launcher script also adds `Content/MacOS/bin` and
`Content/MacOS/libexec` folders to the PATH environment variable, to
so ensure binary tools packaged into Emacs itself are available. This
is done even when not doing a native-comp build. The launcher script
skips setting LIBRARY_PATH if it's not a native-comp build.
This should hopefully resolve both #5 and #7.
An attempt at resolving #8 by getting the GCC compilation step to have
GNU-based `sed` and other commands available. At the very least, I'm
assuming this won't break things. Fingers crossed.
