|
From: Martin W. <ic...@ma...> - 2019-06-01 21:48:59
|
Evan Lavelle wrote: > Some feedback on an MSYS2/mingw64 build (a 64-bit build, with the newer > version of MinGW). This is pretty painless, except that 'make install' > doesn't work. There are various warnings with the gcc 9.1.0 build, but > nothing important - I can post the build output if anyone wants to see it. > Note that this is a clean MSYS2 build, and not a Cygwin build. Yes, gcc 9.x has introduced a bunch of new warnings. Looks like C++ is re-inventing itself again. > The generated Makefile appears to be incorrect for the install step, but > I'm not quite sure how. The 'install' goal depends on 'all', and make runs > through the 'all' dependencies before starting the install step. It gets to > the Bison rule, and decides that parse.h is out of date, because it's older > than parse.cc. It then attempts to carry out the 'mv parse.cc.h', but > fails, since parse.cc.h no longer exists, having already been moved in the > main build. This happens in 3 different Makefiles. The comment here refers > to 'pr3462585' to explain why the Bison rule is carried out this way, but I > can't find anything on pr3462585 on the net. Unfortunately SourceForge renumbered all the bugs, so we lost the connection between bug reports and regression tests, etc. > parse.h and parse.cc actually have the same (visible) timestamp so, at > first sight, this shouldn't happen. My first thought was that it might be a > time resolution problem on Win/MSYS2, so I added .LOW_RESOLUTION_TIME > targets with parse.h prerequisites, but this does nothing (and make > complains that they're high resolution anyway). I also tried running the > install step with the Cygwin make rather than the MSYS2 make, but this > makes no difference (and would probably fail anyway). Running 'stat' in the MSYS2 shell shows the full resolution timestamps. It appears the latest version of bison writes the .hh file before the .cc file, thus breaking our make rules. Also reported in https://github.com/steveicarus/iverilog/issues/247 for Ubuntu. > The manual fix is simply to touch the parse.h files when the build stops, > and re-run the install. > > The next issue is that the build is dynamic, and I don't think this really > works for Windows. To get iverilog to run, you have to ship MinGW's > libstdc++-6.dll, libgcc_s_seh-1.dll, and libwinpthread-1.dll with iverilog. > You can just put them in the same bin directory. But, to get vvp to run, > you have to add lots more dlls (not sure which). The simplest thing to do > is just to install MSYS2 with either the 32-bit or 64-bit toolchain, and > put the toolchain in your path (/cygdrive/c/msys64/mingw64/bin for me, in > my Cygwin path) along with the MSYS2-generated Icarus exes. Not great, and > Pablo's installer gives you an option to install the required DLLs. It > doesn't work without the DLLs, so presumably this option is for people who > already have an MSYS2 installation. > > None of this is necessary with a static build, which is what I do with my > own code. However, that's with hand-written Makefiles, and I'm not sure how > to persuade configure to generate static binaries, or even if it's possible. Well, it's always been that way, and I don't really have the time or motivation to change it (I don't use Windows myself). I think the extra DLLs you need to copy for vvp are libbz, libhistory, libreadline, libtermcap, and zlib. I should probably add that to the instructions on the Wiki. |