Add FFTW, Bison, M4, Flex, readline, ncurses, Abseil, Google test, NGSPICE, ABC, Netgen, Magic, Icarus Verilog, Icestorm #24
Conversation
They are dependencies of NGSPICE which I intend to add in a follow up commit.
Warnings like these can cause problems if the user of the project has configured warnings to be treated as errors.
By request from reviewer.
per-gron
force-pushed
the
m4-bison-flex-fftw
branch
from
1a74858
to
50fd4b5
Compare
|
@QuantamHD I rebased the PR and fixed the conflicts. PTAL. |
NGSPICE depends on Readline. Readline depends on ncurses. The smoke tests depend on Absl and Google test.
Netgen can do LVS checks and more.
The added dependencies are zlib, gperf and bzip2.
This is used for FPGA synthesis for Lattice ICE40 chips.
per-gron
changed the title
|
I added a bunch of more things. Sorry about the huge PR... But in this case I think splitting it up doesn't really make it more reviewable since it's all quite separate. |
|
Once this is reviewed I can continue with Tcl, Yosys, Project Trellis, Nextpnr. That's most of what I have I think. |
| ) | ||
|
|
||
| cc_binary( | ||
| name = "m4", |
There was a problem hiding this comment.
Question: would this manual m4 building work with clang/clang++ as well ?
In verible, we build m4 mentioned in our WORKSPACE file, using plain configure_make().
However, when building with clang:
git clone https://github.com/google/verible.git && cd verible
CC=clang CXX=clang++ bazel build //bazel:m4
we run into compile errors apparently having to do with an undefined symbol used by clang's code-generation ?
../lib/libm4.a(xmalloc.o):xmalloc.c:function xnmalloc: error: undefined reference to '__muloti4'
../lib/libm4.a(xmalloc.o):xmalloc.c:function xnrealloc: error: undefined reference to '__muloti4'
../lib/libm4.a(xmalloc.o):xmalloc.c:function xcalloc: error: undefined reference to '__muloti4'
This means, that verible currently can not be built on MacOS (where clang is the default compiler), which limits the audience; So if there is a way to make m4 build reliably on that platform as well, we (@fangism and me) would be very happy to accept guidance (could be in the shape of a pull request :D) how to make this work in verible.
With regard to this pull request, it probably makes sense to test all of these new build rules also with CC=clang CXX=clang++ to make sure we're somewhat compiler-independent.
There was a problem hiding this comment.
The BUILD rules in this PR are all copied from a repository that uses clang as the compiler, so the answer is yes but with this caveat:
It works only if the m4 binary is linked with LLVM's compiler-rt (as opposed to libgcc). See android/ndk#295 (comment) and the linked LLVM issue https://bugs.llvm.org/show_bug.cgi?id=16404. The main linker flag you need is -rtlib=compiler-rt. A quick way to get it to work is to build with CC=clang CXX=clang++ bazel build --linkopt=-rtlib=compiler-rt @org_gnu_m4//:m4. Another nice and easy way of setting up a clang toolchain is to use this LLVM Bazel toolchain which easily gives you a nearly (it doesn't disable global system header include paths) hermetic toolchain.
There was a problem hiding this comment.
Once I've pulled in the deps that I'm working on now I'd be happy to set up CI that runs Clang and GCC. @mithro could maybe pull some strings to give me access to a GCP project that has Cloud Build enabled? I have a feeling that the CI solutions that can be had for free for FOSS projects are not quite going to be fast enough to be nice to use.
There was a problem hiding this comment.
Is there a way in a bazel BUILD file to automatically enable compiler-rt depending on the toolchain used ?
There was a problem hiding this comment.
@hzeller Last time I checked Bazel did not offer a way to select based on GCC vs Clang. It's really weird to me that they don't offer this, it's really quite common to have to choose copts based on this. I think you could select based on the OS, see https://github.com/tensorflow/tensorflow/blob/master/third_party/clog/BUILD.bazel
Since this is arguably a bug in the toolchain the "proper" way to fix it (short of fixing LLVM) is to change the Bazel toolchain configuration, which is what using https://github.com/grailbio/bazel-toolchain does for you, although that also downloads LLVM binaries.
|
I don't have merge access to this repo, so if someone can push the merge button that'd be good. Then I'd be able to make a fresh follow-up PR without adding to this insanely large one 😄 |
|
@per-gron - Your access level should now be fixed. |
They are dependencies of NGSPICE which I intend to add in a follow up commit.