clang needs to find headers + libraries for compiling with libc++. We
need to add a libcxx argument to cc-wrapper. This means you do not
have to pass in c++ headers directly.
This resolves the last case remaining of #30670. Darwin clang++ now
works properly.
Fixes#30670
https://groups.google.com/forum/#!msg/golang-announce/mVeX35iXuSw/Flp8FX7QEAAJ
We have just released Go 1.11.5 and Go 1.10.8 to address a recently reported security issue. We recommend that all users update to one of these releases (if you’re not sure which, choose Go 1.11.5).
This DoS vulnerability in the crypto/elliptic implementations of the P-521 and P-384 elliptic curves may let an attacker craft inputs that consume excessive amounts of CPU.
These inputs might be delivered via TLS handshakes, X.509 certificates, JWT tokens, ECDH shares or ECDSA signatures. In some cases, if an ECDH private key is reused more than once, the attack can also lead to key recovery.
The issue is CVE-2019-6486 and Go issue golang.org/issue/29903. See the Go issue for more details.
He prefers to contribute to his own nixpkgs fork triton.
Since he is still marked as maintainer in many packages
this leaves the wrong impression he still maintains those.
We don’t need to set -stdlib=libstdc++. This only works on Clang so it
is not good to set it globally. In addition, Clang knows to use
libstdc++ on Linux by default if no stdlib is set:
324f918438/lib/Driver/ToolChains/Linux.cpp (L456)
It’s a good policy to just leave off stdlib for now.
Fixes#29877.
This makes LLVM tools (including dependent tools such as LLD) readily useful in
more situations, foresees such needed additions as BPF and NVPTX, and brings
llvm_6 and newer on par with the current default llvm_5.
This allows building Vala without support for Graphviz; useful for more
minimal installs where we don't want to pull it (and transitively,
pango, gd, etc.) in as a dependency.
- Require Coq 8.6.1+
- Split substituteInPlace call into patchPhase
- Constrain platforms correctly to x86_64 Linux/Darwin, which was all
it supported anyway (there was no way to properly configure i686 builds,
nor cross builds. In the future there might be)
- Minor stylistic cleanups
- Add new 'man' and 'doc' outputs (the previous attempt to move the
build artifact outputs into $lib no longer worked correctly and they
were installed into 'out' instead, this fixes it completely).
- Clean up weird binary artifacts left in $out (that were already
in $lib)
- Wrap ccomp to undefine _FORTIFY_SOURCE; otherwise it causes
annoying warnings on every invocation
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This is to help QT find all the necessary plugin libraries at startup
time, otherwise it freaks out when run out of 'nix-env' environment or
run directly, e.g. `./result/bin/nextpnr-ice40 --gui`. The reason for
this is that none of the traditional paths it looks for are available.
The workarounds for this are to otherwise:
- Install e.g. into environment.systemPackages (presumably it will
then pick up QT libraries in /run/current-system/sw/lib/qt-*)
- Install 'qtbase' into your user environment (qt will also try to
load dependent libraries out of ~/.nix-profile/lib/qt-*)
However, this QT_PLUGIN_PATH wrapping hack is used elsewhere in the
tree, presumably to mitigate these (poor) workarounds, especially for
non-NixOS users. There seems to be no downside to this.
With this, I have been able to run NextPNR's GUI on an Ubuntu 16.04
system using the 'nixGL' hack by simply running the resulting binary
from anywhere (though there seems to be some glitching artifacts in the
floorplan UI, I suspect this is due to a buggy OpenGL stack rather than
any direct problem with NextPNR or the QT libraries themselves).
This does not mark the GUI build as non-broken yet, though. That will
happen in the future after a bit more testing and splitting nextpnr into
separate minimal/GUI attributes.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This requires an absurd, disgustingly gross hack in order to share the
build artifacts necessary for nextpnr to use trellis.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This didn't work remotely (on a server with Nvidia drivers) _or_ on a
local Intel machine with integrated graphics. I presumably messed
something up (a missing dependency), but I'm not sure where. We can fix
it later.
In the mean time, just disable this by hiding it behind a minimal flag.
As a bonus this reduces the closure size by about half, although it's
still surprisingly large (~300MB or so). Part of that is probably
Python, though.
When the GUI is reintroduced in a working manner, we can expose two
nextpnr attributes for the minimal non-GUI build, and the GUI build.
(Note that I have no plans of making Python optional, since it's
extremely valuable in general and much more lightweight than qtbase.)
Signed-off-by: Austin Seipp <aseipp@pobox.com>
* add generic x86_32 support
- Add support for i386-i586.
- Add `isx86_32` predicate that can replace most uses of `isi686`.
- `isi686` is reinterpreted to mean "exactly i686 arch, and not say i585 or i386".
- This branch was used to build working i586 kernel running on i586 hardware.
* revert `isi[345]86`, remove dead code
- Remove changes to dead code in `doubles.nix` and `for-meta.nix`.
- Remove `isi[345]86` predicates since other cpu families don't have specific model predicates.
* remove i386-linux since linux not supported on that cpu
Michael Raskin
Jörg Thalheim
Will Dietz
Matthew Bauer
Vladimír Čunát
Kosyrev Serge
Kosyrev Serge
allowthere
Francois-Rene Rideau
Domen Kožar
Jörg Thalheim
Joachim F
Alyssa Ross
Silvan Mosberger
Ingolf Wagner
taku0
Luka Blaskovic
Will Dietz
Matt McHenry
Tim Steinbach
Theodore Witkamp
Frederik Rietdijk
Jan Tojnar
Viktor Kleen
rnhmjoj
Frederik Rietdijk
adisbladis
Ben Wolsieffer
R. RyanTM
Orivej Desh
worldofpeace
Milan Svoboda
Andrew Dunham
Austin Seipp
Yegor Timoshenko
Dmitry Kalinkin
Franz Pletz
Pavol Rusnak
Thomas Mader
Jorge Acereda
Daniel Goertzen