libungif was merged into giflib in 2006, and hasn't been updated
since. All non-broken packages still using it build fine with giflib.
See <http://giflib.sourceforge.net/history.html>.
This approach applies to _all_ RUN_TEMACS calls and successfully removes -dev paths from the closure and reduces the closure size from ~1.4G to just under ~464M.
It's also less brittle than having in-tree patches.
continuation of #109595
pkgconfig was aliased in 2018, however, it remained in
all-packages.nix due to its wide usage. This cleans
up the remaining references to pkgs.pkgsconfig and
moves the entry to aliases.nix.
python3Packages.pkgconfig remained unchanged because
it's the canonical name of the upstream package
on pypi.
This makes it much easier to create customisations around emacs via
the a new convenience passthru attr:
- `emacs.pkgs`: What used to be emacsPackages is now `emacs.pkgs`
The previous versioned names `emacs*Packages` have been moved to
aliases.nix and are now considered deprecated in favour of `emacs*.pkgs`.
siteVersionDir isn't a full path, it's just the name of the version
directory entry in $out/share/emacs, e.g. "27.1", so since
d1b0eef9b5 ("emacs: Don't use interpolation for version"), we've been
trying to remove a non-existent directory. This would have been
caught if we hadn't been giving -f to rm unnecessarily, because -f
suppresses errors. As well as fixing the path, I've removed the -f
from rm. Doing this to the line above as well revealed that rm-ing
$out/var was no longer necessary, since nothing has been put there
since ac23a7c459 ("emacs: 25.3 → 26.1") -- it would now only be
created if we set the --with-gameuser configure option, which we
don't.
Emacs 27 doesn't use ImageMagick by default to display images [1]:
** Emacs no longer defaults to using ImageMagick to display images.
This is due to security and stability concerns with ImageMagick. To
override the default, use 'configure --with-imagemagick'.
[1] https://github.com/emacs-mirror/emacs/blob/emacs-27.1/etc/NEWS#L96-L98
The given paths gives rise to errors such as,
```
x86_64-unknown-linux-gnu-gcc-9.3.0: fatal error: cannot execute ‘as’: execvp: No such file or directory
compilation terminated.
```
in the `*Async-native-compile-log*` buffer.
Fixes <https://github.com/nix-community/emacs-overlay/issues/69>
The -B flag to gcc (and libgccjit) allows us to specify where it can
find things it needs to correctly compile code (both programs and
libraries) without adjusting any environmental flags: So, no need to
wrap the program for a PATH entry containing binutils, and no need to
explicitly pass a linker path anymore.
The -B flag to gcc (and libgccjit) allows us to specify where it can
find things it needs to correctly compile code (both programs and
libraries) without adjusting any environmental flags: So, no need to
wrap the program for a PATH entry containing binutils, and no need to
explicitly pass a linker path anymore.
This way, we don't have to drag clang or binutils/binutils-wrapped
into the emacs closure, and can instead rely on using the correct one
for the platform we're running on.
Co-authored-by: Matthew Bauer <mjbauer95@gmail.com>
Since Darwin's linker does not understand LIBRARY_PATH, we have to set
the library path as explicit linker flags: This requires a very recent
feature/native-comp emacs revision, but it runs on Darwin and
correctly compiles files at runtime.
The latter doesn't exist on Darwin (and, presumably, other targets as
well). This change allows emacsGcc from emacs-overlay to attempt to
build where previously, the derivation would error out.
