Commit e245c4f226979ccb717cccc8f82b2b0a0f96bdac on Emacs' master branch
added support for optional flags to the --with-native-compilation
configure flag.
This change to output of ./configure --help broke the native comp
detection present in our build script.
This change adds support for the new configure flag format, while also
using it to specify AOT when enabled.
It is still backwards compatible with the configure script in older
commits.
Fixes#76
Since the latest update of `libgccjit` in brew to version 12, emacs does
not build again. Problem is that now dylib exists in multiple locations,
and `MAC_CFLAGS` environment variable is not filled correctly in
`configure.ac`. This commit fixes the issue.
When building Emacs 28.x the build script will attempt to patch
configure.ac if needed to support the latest version of libgccjit which
renamed libgccjit.so to libgccjit.dylib.
Fixes#72
Add support for naming release and builds accordingly when given a git
ref for a pretest (90 or above patch number) or release
candidate ("-rcX" at the end of the tag).
This finally makes Emacs.app with native-comp fully self-contained, no
longer requiring the GCC Homebrew formula to be installed when
loading *.eln files that link against
/usr/local/lib/gcc/11/libgcc_s.1.dylib.
By adding the signing entitlement
com.apple.security.cs.allow-dyld-environment-variables, which allows
dynamic library loading to be controlled via DYLD_* environment
variables. It seems the lack of this was preventing Emacs from loading
the bundled libgcc_s.1.dylib file from Contents/Frameworks.
Fixes#53
This allows much shorter shared library link paths within *.eln files
compared to when using @executable_path, which leaves enough space in
them to sign all *.eln files, while directly having them linked against
the embedded copy of GCC shared libraries.
It seems like Ruby's FileUtils.cp_r method especially was messing with
some file attributes, causing Emacs to print details about loading
various elisp files on startup. While when Emacs.app is copied into the
output build directory using "cp -a" instead of FileUtils.cp_r it does
not exhibit this behavior.
It seems homebrew bottle of GCC for macOS Monterey (12.0) have changed their
directory structure slightly, which caused an issue were we were trying
to rename a specific directory to the same name it already had.
This behavior is still required as it looks like GCC on macOS
Catalina (10.15), the GCC homebrew bottle still uses the old directory
structure.
Relinking is currently failing for some of the *.eln files. See #60 for
details of the error.
Long-term plan is to investigate native-comp's compilation options to
hopefully resolve this issue.
