Open tmagik opened 5 years ago
It looks like this is due to the ProtoBuf implementation and is fixed: https://github.com/protocolbuffers/protobuf/issues/4425
Can you try updating the version used by FIRRTL and see if that fixes the issue? https://github.com/freechipsproject/firrtl/blob/7b4bde7e9942e9a25fd730ace5a8c6369707085e/build.sbt#L78
I should note that as far as I know, there is no JVM JIT yet for RISC-V, so I suspect this is going to run really slowly.
I bumped to '-v361' which is now very slowly building, so maybe this will work if the top-level Makefile understands it needs to rebuild firrtl now...
Great! Would you like to PR these changes?
It appears that build.sc is relying on protobuf's release artifacts, which unfortunately still don't provide a riscv64 binary as of today.
https://github.com/chipsalliance/firrtl/blob/master/build.sc#L241
I am sed'ing out the versions to match system protobuf on Arch, and successfully compiled firrtl on both x86_64 and riscv64.
https://github.com/archlinux/svntogit-community/commit/e0f33c41b857f8cbee25f6083a5a256fa7d7dabc
I have also tried to alter the checkSystemProtocVersion
flag only, which unfortunately doesn't work because protocVersion
affects also the version of com.google.protobuf:protobuf-java
and breaks when they don't match.
Do you think it a good idea to just set protocVersion
to systemProtocVersion
when they don't match, but checkSystemProtocVersion
is falsy?
Type of issue: other enhancement
commit abaa38f4f63b35105796916e3df2ccf5c1639f65 (HEAD) Author: Jack Koenig <jack.koenig3@gmail.com> Date: Thu Aug 23 18:19:47 2018 -0700
Linux buildroot 4.15.0-00048-gfe92d7905c6e #6 SMP Wed Sep 5 03:57:45 UTC 2018 riscv64 GNU/Linux
What is the use case for changing the behavior? A RiscV host should be able to compile rocket-chip
Impact: unknown
Development Phase: request
Other information: https://github.com/sifive/freedom