https://hydra.nixos.org/build/70700906
I opened an upstream bug, but their bug system is e-mail based and I
haven't got a single reply which contains an web link :(
Disables -Werror
Alternatively one could use
NIX_CFLAGS_COMPILE = [
"-Wno-error=implicit-fallthrough"
"-Wno-error=zero-as-null-pointer-constant"
"-Wno-error=shadow"
];
Since at least d7bddc27b23da8ce7bc19cfeeeb0cbebdb5a4410, we've had a
situation where one should depend on:
- `stdenv.cc.bintools`: for executables at build time
- `libbfd` or `libiberty`: for those libraries
- `targetPackages.cc.bintools`: for exectuables at *run* time
- `binutils`: only for specifically GNU Binutils's executables,
regardless of the host platform, at run time.
and that commit cleaned up this usage to reflect that. This PR flips the
switch so that:
- `binutils` is indeed unconditionally GNU Binutils
- `binutils-raw`, which previously served that role, is gone.
so that the correct usage will be enforced going forward and everything
is simple.
N.B. In a few cases `binutils-unwrapped` (which before and now was
unconditionally actual GNU binutils), rather than `binutils` was used to
replace old `binutils-raw` as it is friendly towards some cross
compilation usage by avoiding a reference to the next bootstrapping
change.
Don't rely on questionable impact of DT_RPATH on dlopen().
This is a bit of a messy subject, but probably the clearest
reference to motivate *not* relying on how dlopen() behaves
in the presence of RPATH or RUNPATH is the following:
https://sourceware.org/ml/libc-hacker/2002-11/msg00011.html
FWIW the dlopen() manpage only mentions the the RPATH
and RUNPATH in the "executable file for the calling program";
no mention of the executable files for libraries--
this has been brought to the attention of the relevant
parties and AFAICT nothing has been done.
The best reference for glibc behavior is
apparently to ... "try it and see".
Luckily a generous soul did exactly that
and reported the findings:
https://www.spinics.net/lists/linux-man/msg02291.html
Qt wrote on the subject a bit when they were bit by this,
linking to the above articles (directly or indirectly).
See:
http://blog.qt.io/blog/2011/10/28/rpath-and-runpath/
--------
Since we know the path of libGL at build-time for libepoxy,
there's a simple solution we can use to avoid all of this:
simply teach libepoxy to explicitly look in the libGL path.
This commit patches libepoxy to accomplish this,
looking to "LIBGL_PATH" as a fallback if it cannot find
the libraries otherwise.
---------
This fixes use of libepoxy w/musl on NixOS!
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/alembic/versions.
These checks were done:
- built on NixOS
- ran `/nix/store/739vhfkmanak88f4g6yzqkrsid2mi59r-alembic-1.7.7-bin/bin/abcls -h` got 0 exit code
- ran `/nix/store/739vhfkmanak88f4g6yzqkrsid2mi59r-alembic-1.7.7-bin/bin/abcls --help` got 0 exit code
- ran `/nix/store/739vhfkmanak88f4g6yzqkrsid2mi59r-alembic-1.7.7-bin/bin/abcls help` got 0 exit code
- ran `/nix/store/739vhfkmanak88f4g6yzqkrsid2mi59r-alembic-1.7.7-bin/bin/abctree -h` got 0 exit code
- ran `/nix/store/739vhfkmanak88f4g6yzqkrsid2mi59r-alembic-1.7.7-bin/bin/abctree --help` got 0 exit code
- ran `/nix/store/739vhfkmanak88f4g6yzqkrsid2mi59r-alembic-1.7.7-bin/bin/abcconvert --help` got 0 exit code
- found 1.7.7 with grep in /nix/store/739vhfkmanak88f4g6yzqkrsid2mi59r-alembic-1.7.7-bin
- directory tree listing: https://gist.github.com/ef5ac862933e11b24f7c82cf0d0c4b16
This is the only package that still needs ECJ and has no dependencies.
It's ancient and unmaintained and should just be removed.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/libidn/versions.
These checks were done:
- built on NixOS
- ran `/nix/store/0i5mh79ayn9s5hzk33qc4r46iv6vq39b-libidn-1.34-bin/bin/idn -h` got 0 exit code
- ran `/nix/store/0i5mh79ayn9s5hzk33qc4r46iv6vq39b-libidn-1.34-bin/bin/idn --help` got 0 exit code
- ran `/nix/store/0i5mh79ayn9s5hzk33qc4r46iv6vq39b-libidn-1.34-bin/bin/idn help` got 0 exit code
- ran `/nix/store/0i5mh79ayn9s5hzk33qc4r46iv6vq39b-libidn-1.34-bin/bin/idn -V` and found version 1.34
- ran `/nix/store/0i5mh79ayn9s5hzk33qc4r46iv6vq39b-libidn-1.34-bin/bin/idn --version` and found version 1.34
- ran `/nix/store/0i5mh79ayn9s5hzk33qc4r46iv6vq39b-libidn-1.34-bin/bin/idn -h` and found version 1.34
- ran `/nix/store/0i5mh79ayn9s5hzk33qc4r46iv6vq39b-libidn-1.34-bin/bin/idn --help` and found version 1.34
- found 1.34 with grep in /nix/store/0i5mh79ayn9s5hzk33qc4r46iv6vq39b-libidn-1.34-bin
- directory tree listing: https://gist.github.com/2097e7f4c50acbee75a30738c68f417c
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/lmdb/versions.
These checks were done:
- built on NixOS
- ran `/nix/store/lycr0rb3lgdhnjfsl44wv9vw74gpsh44-lmdb-0.9.22-bin/bin/mdb_stat -V` and found version 0.9.22
- ran `/nix/store/lycr0rb3lgdhnjfsl44wv9vw74gpsh44-lmdb-0.9.22-bin/bin/mdb_copy -V` and found version 0.9.22
- ran `/nix/store/lycr0rb3lgdhnjfsl44wv9vw74gpsh44-lmdb-0.9.22-bin/bin/mdb_dump -V` and found version 0.9.22
- ran `/nix/store/lycr0rb3lgdhnjfsl44wv9vw74gpsh44-lmdb-0.9.22-bin/bin/mdb_load -V` and found version 0.9.22
- found 0.9.22 with grep in /nix/store/lycr0rb3lgdhnjfsl44wv9vw74gpsh44-lmdb-0.9.22-bin
- directory tree listing: https://gist.github.com/f4d443d41dd66aa5f5038de9319c607d
Darwin machines come with a case-insensitive filesystem by default. The
gflags package's source contains a file 'BUILD' and the build process
attempts to create a directory called 'build', which fails on
case-insensitive filesystems.
Add a prePatch hook to rename the BUILD file (which is for use with an
unrelated build tool) to something that doesn't conflict with the
'build' directory. This hook allows this derivation to be built on
case-insensitive filesystems.
Add metadata to the derivation because previously it had none.
