This reverts commit 8f07d4bd780a24dcf33be46d8cbfc6163fcdde0e. The build
failure blocking this package has been fixed in the meanwhile. Thanks to
@basvandijk for the heads-up.
(cherry picked from commit 56d033ac1b00a8b29bc29589312d2f5024656bd3)
We are currently carrying a number of vala versions where each version
is essentially just a copy of the earlier version.
This PR gets rid of a ton of duplication and uses a standard builder.
Secondly, we add a definition for the latest vala 0.34.1.
Lastly, we add a generic "vala" that refers to the latest stable
version.
I have tried changing the definitions for "simple-scan" and "valum" to use
the latest vala version and they at least compile OK so I'll try a
massive sed job to replace all the definitions later to simply use the
latest version through "vala" instead of specifying a version directly.
According to upstream:
"Well-maintained packages are expected to always build with the latest
stable Vala version."
Maybe this means that my generic builder is then no longer necessary. Oh well...
I added myself to the maintainer array for vala although I have no
interest in the language - this was purely a nix exercise for me but I
thought it was reasonable to be the one to clean up the mess if this has
side effects...
Cc: @antono and @lethalman
This reinstates the libSystem selective symbol export machinery we used
to have, but locks it to the symbols that were present in 10.11 and skips
the actual compiled code we put into that library in favor of the system
initialization code. That should make it more stable and less likely to
do weird stuff than the last time we did this.
The OS is identified as "10.4" rather than "osx". This commit removes
the 'rt' build script's hard coding of the "osx" suffix when building on
darwin since the cmake configuration falls back to building a 10.4
compatible libclang_rt.
This makes several adjustments around what is linked into JRE.
* system giflib, libjpeg, zlib are now used unconditionally;
* libstdc++ is linked dynamically.
For full version:
* GTK+ and GNOME libraries are linked;
* Extra X11 libraries are linked;
* CUPS is linked;
* libmagic (file) is linked.
For minimal version:
* All X11 support is removed;
* Sound support is removed.
* Fonts and their support are not lined.
jre8_headless is added as a minimal build.
Overall this adds support for all things GUI into the default Java build and
removes them from the minimal build.
Allow mlton to compile in a more barren sandbox. The bootstrapping
binaries for darwin have dynamic linking dependencies outside of the nix
store. This patch shifts them to point to the appropriate library within
the nix store.
Fixes#18840: too large closure of mesa_drivers.
Tested atop 16.09:
- clang compiles a hello-world app;
- mesa seems to link OK;
- ispc builds.
Size comparison:
- 80 MB of full llvm-3.7 on 16.03;
- 200 MB of full llvm-3.9 on 16.09 before this patch;
- 50 MB of libLLVM after this commit.
Make the existing ghdl recipe more flexible, and introduce "ghdl_llvm"
as a package in addition to "ghdl_mcode". This seems to specifically
require llvm 3.5, though. The flavour is also encoded in the package name.
cc @viric
- Set a cmake flag to allow cmake to find CUDA automatically.
- Pass -D_FORCE_INLINES to work around
/nix/store/8sl4jfs3nq0pkq4gg655s3axrxdx7z29-glibc-2.24-dev/include/string.h: In function 'void* __mempcpy_inline(void*, const void*, size_t)':
/nix/store/8sl4jfs3nq0pkq4gg655s3axrxdx7z29-glibc-2.24-dev/include/string.h:650:42: error: 'memcpy' was not declared in this scope
https://github.com/BVLC/caffe/issues/4046
This fixes OpenSubdiv and Blender.
Darwin systems need to be able to find CoreFoundation headers as well as
libc headers. Somehow, gcc doesn't accept any "framework" parameters
that would normally be used to include CoreFoundation in this
situation.
HACK: Instead, this adds a derivation that combines the two. The result
works but probably not a good long term solution.
ALTERNATIVES: Maybe sending patches in to GCC to allow
"native-system-framework" configure flag to get this found.
gcc needs to be able find system headers. Without this, gcc fails to build because
/usr/include is not available.
Note: stdenv.libc should be available for all stdenv's, I think.
This should get gcc48, gcc5, and gcc6 working again.
Also: use makeLibraryPath, and makeSearchPathOutput for LIBRARY_PATH and
CPATH. This is a refactor but it also fixes an issue with zlib.
