[J-core] Updated ghdl toolchain build script.

[Rob Landley]

On 8/26/20 2:26 AM, Rob Landley wrote:
> The ghdl toolchain script I posted almost a year ago bit-rotted because the
> upstream git repos it's building changed. Attached is a new one, I really need
> to get binary debian packages loaded into a ppa or some such.

I updated the build script with nextpnr and iceweasel, which can actually build
an ice40 bitstream that boots on real hardware. (And already optimizes _better_
than lattice's toolchain.) And gave it a proper git repo:

  https://github.com/landley/yogh

I'm trying* to clean it up so the resulting binaries are portable and I can
point you at a binary tarball and "license compliance source tarball"**, but
it's being stroppy***.

Rob

* Yes it's all random git snapshots of repos already on github, no I didn't
include the .git directories for them because then it would be over 100 megs,
but there's gplv3 crap in here I don't want to get on me. Luckily so far I've
only had to send https://github.com/YosysHQ/nextpnr/pull/501 to an ISC licensed
package, the rest I've just fed command line arguments and environment variables
to so far...

* Yes I should put that over to github.com/j-core and do stuff there, but Jeff
has 2fa set up for that with login notifications that go to him, not me, and
although I can add my account as a collaborator for _existing_ repos you have to
log in as j-core to create NEW repos and I can't be a collaborator until the
repo exists...


** The problem is yosys and ghdl both want to dlopen() other packages so you
can't statically link EITHER of them or you hit the old "the dynamically linked
instance of malloc() maintains a heap stored in the pointer in the library, and
the statically linked malloc() maintains a heap stored in the pointer statically
linked into the binary, and the code here calls malloc() against one heap
instance and free() against the other heap instance and now you have at BEST
leaked memory and more likely either corrupted the receiving heap or thrown a
stack trace and aborted" problem. And since half this crap is written in
<strike>cobol</strike>ada it needs to use its own magic copy of gcc with ada
support added, meaning I can't point it at one that'll link against musl instead
of glibc and at least _mitigate_ that problem. Oh, and it won't use gnat-6 it
insists on gnat-8 which devuan hasn't packaged, which is CRAPTACULAR to build
from source, and which https://www.adacore.com/download only provides nightly
snapshots of with NO HISTORY of previous versions (just a link to TONIGHT's and
nothing else) but has horrible stupid like adding -2019 to library names that
then get pulled into the resulting binary's dynamic link dependency list and
CHANGE EVERY JANUARY. Ahem. Working on it...