The wrapper is not needed because the runpath is already set correctly,
and LD_LIBRARY_PATH was breaking child processes linked against
different libc versions.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
Since the 0.21 upgrade, the host `$PATH` is not forwarded anymore by
default to the sandboxes in charge to realize Bazel actions. This
default change broke the `py_binary` rule among other things.
Every python binary is wrapped in a stub in charge to setup the
execution environment. Currently, this stub's shebang points to a
`/usr/bin/env python` which cannot be resolved with the current
`$PATH`.
This results in breaking any build pipeline requiring the use of
python at some point. On top of the incorrect shebang, the stub
template is unable to find the actual python binary using
`SearchPath`.
This PR fixes those two things by re-writing the stub template shebang
to the actual python binary and by substituting the faulty default
python binary lookup to the right one.
This has two main advantages:
- By setting hasSharedObjects = true, buildOcaml will automatically
include a setup-hook.sh that sets CAML_LD_LIBRARY_PATH in dependent
expressions. This is needed to pick up dllzarith.so properly which is
shipped as part of the library.
- We can kill the ugly assert in the expression and instead change it
to use minimumSupportedOcamlVersion.
(Note: this was reverted in b44d5136e8, but the change is
exactly equivalent -- I wasn't sure what impact zarith might actually
have without checking OfBorg, which I wanted to do first.)
Signed-off-by: Austin Seipp <aseipp@pobox.com>
This has two main advantages:
- By setting hasSharedObjects = true, buildOcaml will automatically
include a setup-hook.sh that sets CAML_LD_LIBRARY_PATH in dependent
expressions. This is needed to pick up dllzarith.so properly which is
shipped as party of the library.
- We can kill the ugly assert in the expression and instead change it
to use minimumSupportedOcamlVersion.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
- 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>
Before this commit it built fine a few times for me,
i.e. without the single test, but it failed on Hydra anyway.
I guess jtojnar also tested the final expression with all tests,
so apparently they are sensitive the the kind of machine they run on.
The build was broken by the python 3.7 switch, which caused an
incompatible change in the way cython generates files:
https://github.com/Kozea/tinycss/issues/17
This is solved by removing the pre-generated file and re-generating it
at build time.
With the previous PyPy3 change, this reduces the compile time from
~1m30s to roughly 36s (compared to the original, serial, Python 3 build
time of 2:30s).
Signed-off-by: Austin Seipp <aseipp@pobox.com>
PyPy3 offers tremendous speedups for IceStorm tools written in Python,
including tools used at compile-time to generate the chip databases, and
runtime tools distributed to users, such as icebox_vlog.
For example, on my ThreadRipper 1950X, build times for IceStorm
consistently go from 2m30s -> 1m30s with this change, a 40% improvement,
simply due to improvements in raw CPU efficiency. (This is also worsened
by the fact the build is currently serial, but that can easily be fixed
anyway.)
On top of that, tools distributed to users are also now run using PyPy.
Utilities such as icebox_vlog are useful for post-bitstream testing, for
instance, and also are improved due to improved CPU efficiency as well.
For example, when "decompiling" an ICE40 bitstream for HX8K devices,
containing a synthesized copy of PicoRV32 (from the NextPNR demos), the
runtime of icebox_vlog is cut from 25 seconds to 9 seconds consistently
with this change alone.
Normally, picking a Python interpreter outright for Python-based code is
a "bad idea", but in the case of IceStorm it should be perfectly safe,
and an excellent improvement for users. There are a few reasons for
this:
- IceStorm uses pure Python 3 and nothing else. There are no
requirements for any 3rd party packages, which might cause annoying
incompatibilities, and PyPy has historically shown very strong core
Python compatibility.
- IceStorm is NOT a set of Python libraries, it is a set of tools,
some of which, coincidentally, are written in Python. It is (normally)
bad form to fix libraries to certain interpreters versions if the reason
strictly isn't "it doesn't work/isn't compatible". That is not the case
here. These tools may later be used by other programs, such as NextPNR,
but the Python interpreter is ultimately not that important in quesion
for the user. In this sense, there is almost no downside to picking
PyPy explicitly if it offers far better performance.
(Point 2 is not actually strictly true; there are some distributed .py
files that you can import from but they are basically just static
classes that are imported by tools like nextpnr; this is expected.)
Because of this, users should see very little change except better
performance for IceStorm tools on their machines.
Note that PyPy is not supported on aarch64 -- this only applies to
x86_64 machines.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
Adds the missing dependencies `google-i18n-address`, `pycountry` and
`html5lib` from the `pythonPackages` subtree.
See also https://hydra.nixos.org/build/86535305
0.21 removed the bundled openjdk-distribution. Instead, tries to fetch
the “right” distribution on-the-fly when building.
So we need to provide our own openjdk.
According to
https://github.com/bazelbuild/bazel/issues/6865#issuecomment-447261288
we should set `--host_javabase="@local_jdk//:jdk` if we want to do
that. This uses the jdk that is currently in the environment, which is
openjdk 8 in our case. 0.21 defaulted to a toolchain for JDK9, which
we don’t package in nixpkgs, so we use the JDK8 toolchain.
This commit also replaces the line-number-based sed invocations with
something more stable.
R. RyanTM
Will Dietz
Will Dietz
Tim Steinbach
Christoph Hrdinka
Jörg Thalheim
Jan Tojnar
Jörg Thalheim
Anders Kaseorg
Orivej Desh
Robert Schütz
Robert Schütz
Vladyslav M
Matthew Bauer
Félix Baylac-Jacqué
Patrick Mahoney
Yorick van Pelt
Francesco Gazzetta
Austin Seipp
Mario Rodas
nagato.pain
Roman Volosatovs
Timo Kaufmann
Sebastien Bourdeauducq
Pierre-Étienne Meunier
worldofpeace
Gabriel Ebner
nyanloutre
Peter Simons
Kévin Rauscher
xeji
Averell Dalton
Vladimír Čunát
zimbatm
Jethro Kuan
Cole Mickens
Profpatsch
José Romildo Malaquias
Vincent Laporte
Thomas Tuegel
Michael Weiss
Dmitry Kalinkin
Yegor Timoshenko
Michael Raskin
Eelco Dolstra
Peter Hoeg
Andrew Childs
Robin Gloster
Franz Pletz
Danylo Hlynskyi
Tim Cuthbertson
Maximilian Bosch
Elis Hirwing
markuskowa
Elmar Athmer
Herwig Hochleitner
