Apple's codesign CLI toolthrows a "bundle format unrecognized" error if
there are any folders within the application that contain two dots in
their name.
Hence we need to get rid of the one instance of that we end up with from
GCC, and update the native-comp patch accordingly.
As of writing, this means renaming:
Emacs.app/Contents/MacOS/lib/gcc/11/gcc/x86_64-apple-darwin20/11.1.0
To:
Emacs.app/Contents/MacOS/lib/gcc/11/gcc/x86_64-apple-darwin20/11
This seems to be the cause of SVG rendering crashing, as it re-links
libiconv.2.dylib from /usr/lib/libiconv.2.dylib to
@executable_path/lib/lib/libiconv.2.dylib within libintl.8.dylib. When
this re-linking does not happen, SVG rendering works without crashing
Emacs.
Some further testing is needed by installing brew dependencies by
building them from source, in an attempt to get various libraries all
linking to homebrew-built versions, to get as many shared libraries as
possible embedded into the application bundle.
Fixes#12
Recent builds places the native-lisp cache folder within
Contents/Resources on macOS, and correctly deals with finding them. This
means the Contents/lisp and Contents/native-lisp symlinks are no longer
needed.
Hence we skip their creation altogether if we find any
Contents/Resources/native-lisp/**/*.eln files.
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.
