Only apply w/musl since while it's wrong everywhere it apparently
hasn't broken things entirely w/glibc so keep things as they were.
Patch regenerated from original so that it applies
which isn't saying much since it's simple :).
Source:
https://patchwork.ozlabs.org/patch/154298/
IRC chat on #musl with Rich and others endorses this,
at least at the conceptual level of no shared library
should be using initial-exec TLS.
Fixes various uses of libgomp that previously crashed (before 1.1.20)
or encounter errors (post-1.1.20), such as pythonPackages.cython .
This includes the initialy commit was done by @Mic92 plus a few fixes
from my side. So essentially this avoids patching statically linked
executables and also speeds up searching for ELF files altogether.
I've tested this by comparing the outputs of all the derivations which
make use of this hook using the following Nix expression:
let
getPackagesForRev = rev: with import (builtins.fetchGit {
url = ./.;
inherit rev;
}) { config.allowUnfree = true; }; [
cups-kyodialog3 elasticsearch franz gurobi javacard-devkit
masterpdfeditor maxx oracle-instantclient powershell reaper
teamviewer unixODBCDrivers.msodbcsql17 virtlyst wavebox zoom-us
];
pkgs = import <nixpkgs> {};
baseRev = "ef764eb0d8314b81a012dae04642b4766199956d";
in pkgs.runCommand "diff-contents" {
chset = pkgs.lib.zipListsWith (old: new: pkgs.runCommand "diff" {
inherit old new;
nativeBuildInputs = [ pkgs.nukeReferences ];
} ''
mkdir -p "''${NIX_STORE#/}"
cp --no-preserve=all -r "$old" "''${NIX_STORE#/}"
cp --no-preserve=all -r "$new" "''${NIX_STORE#/}"
find "''${old#/}" "''${new#/}" \
\( -type f -exec nuke-refs {} + \) -o \( -type l -delete \)
mkdir "$out"
echo "$old" > "$out/old-path"
echo "$new" > "$out/new-path"
diff -Nur "''${old#/}" "''${new#/}" > "$out/diff" || :
'') (getPackagesForRev baseRev) (getPackagesForRev "");
} ''
err=0
for c in $chset; do
if [ -s "$c/diff" ]; then
echo "$(< "$c/old-path") -> $(< "$c/new-path")" \
"differs, report: $c/diff" >&2
err=1
fi
done
[ $err -eq 0 ] && touch "$out"
''
With these changes there is only one derivation which has altered
contents, which is "franz". However the reason why it has differing
contents is not directly because of the autoPatchelfHook changes, but
because the "env-vars" file from the builder is in
"$out/opt/franz/env-vars" (Cc: @gnidorah) and we now have different
contents for NIX_CFLAGS_COMPILE and other environment variables.
I also tested this against a random static binary and the hook no longer
tries to patch it.
Merges: #47222
The unfree variant of elasticsearch uses autoPatchelfHook and since we
removed the dependency on file for the hook itself in
58a97dfb491be6ae92499c3f819440f281d826a1 we no longer have zlib
propagated.
So we need to explicitly state that dependency here.
Signed-off-by: aszlig <aszlig@nix.build>
Cc: @apeschar, @basvandijk
The "maxx" package recursively runs isExecutable on a bunch of files and
since the change to use "readelf" instead of "file" a lot of errors like
this one are printed during build:
readelf: Error: Not an ELF file - it has the wrong magic bytes at the
start
While the isExecutable was never meant to be used outside of the
autoPatchelfHook, it's still a good idea to silence the errors because
whenever readelf fails, it clearly indicates that the file in question
is not a valid ELF file.
Signed-off-by: aszlig <aszlig@nix.build>
If the ELF file is not an executable, we do not get a PT_INTERP section,
because after all, it's a *shared* library.
So instead of checking for PT_INTERP (to avoid statically linked
executables) for all ELF files, we add another check to see if it's an
executable and *only* skip it when it is and there's no PT_INTERP.
Signed-off-by: aszlig <aszlig@nix.build>
Fixes a critical issue with macOS
[NEWS](https://bitbucket.org/mituharu/emacs-mac/raw/master/NEWS-mac)
* emacs-26.1-mac-7.2 (2018-09-09)
** Fixed bugs
*** Buffer contents are not displayed on macOS 10.14.
This is mainly because now NSViews are backed by Core Animation Layer
(layer-backed) by default and non-deferred drawing into views no
longer works. Instead of switching to deferred drawing (i.e., draw
only inside -[NSView drawRect:]), we draw into our own backing bitmap
in a non-deferred way as before, and update the view contents with the
resulting image via -[NSView updateLayer]. This "application-side
double buffering" is also available on OS X 10.8 - macOS 10.13 if you
set the frame parameter `inhibit-double-buffering' to nil when
creating a frame. Just like on macOS 10.14, such a frame does not do
LCD smoothing.
*** Screenshot grabbed via Services is displayed in wrong size when we
have display mirroring between Retina and non-Retina displays.
*** Cursor movement just after frame resize sometimes leaves garbage.
*** Crash by the Fall_threads call from the GUI thread at the select
emulation when there are multiple Lisp threads.
*** Info title has ASCII underline unlike other window systems.
*** Vertical scroll bar is created as horizontal if frame font height
is short.
** Improvements
*** macOS 10.14 adds property :appearance to (mac-application-state).
The value may be "NSAppearanceNameAqua" or "NSAppearanceNameDarkAqua".
*** Add new color format "mac:COLOR-LIST-NAME:COLOR-NAME" and
"mac:COLOR-NAME" (shorthand for "mac:System:COLOR-NAME"). The actual
color may be different depending on the global appearance setting on
macOS 10.14. For example, "mac:textColor" is black on the Light Mode
but is white on the Dark Mode.
*** Default frame colors respect appearance setting on macOS 10.14.
Now the default frame foreground/background color is
"mac:textColor"/"mac:textBackgroundColor", respectively. Changes of
the system setting of the global appearance are dynamically reflected.
*** New function `mac-color-list-alist' to get the available
combinations of COLOR-LIST-NAMEs and COLOR-NAMEs. Note that this
value is dependent on user environment and OS version. Also, some
combinations may represent image patterns rather than colors. For the
former cases, `(color-values "mac:COLOR-LIST-NAME:COLOR-NAME")'
returns nil.
The compilers themselves can pull them from `bootPkgs`, where they
should always come from anyways. This enforces that, simplifies that
code, and allows use to avoid more `rec { ... }` too.
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/libtins/versions.
These checks were done:
- built on NixOS
- Warning: no binary found that responded to help or version flags. (This warning appears even if the package isn't expected to have binaries.)
- found 4.0 with grep in /nix/store/izz1bkj35g5bb6kvqa5kqgb376xhardg-libtins-4.0
- found 4.0 in filename of file in /nix/store/izz1bkj35g5bb6kvqa5kqgb376xhardg-libtins-4.0
- directory tree listing: https://gist.github.com/26990576c9472ca38b4d21613157856b
The `overrideScope` bound by `makeScope` (via special `callPackage`)
took an override in the form `super: self { … }`. But this is
dangerously close to the `self: super { … }` form used by *everything*
else, even other definitions of `overrideScope`! Since that
implementation did not even share any code either until I changed it
recently in 3cf43547f4be03d1d6eb0bbfc557e2dbc13b4095, this inconsistency
is almost certainly an oversight and not intentional.
Unfortunately, just as the inconstency is hard to debug if one just
assumes the conventional order, any sudden fix would break existing
overrides in the same hard-to-debug way. So instead of changing the
definition a new `overrideScope'` with the conventional order is added,
and old `overrideScope` deprecated with a warning saying to use
`overrideScope'` instead. That will hopefully get people to stop using
`overrideScope`, freeing our hand to change or remove it in the future.
