Issues when cross-compiling for Windows

[DavidC-75]

Hi,

The traditional way to build icarus verilog for Windows seems to be using Msys. I didn't want to embark on this (sometimes complicated) path, and as a fun experiment I decided to build on linux instead, using a cross compiler (thanks mxe !!)

The process is very straightforward:

./configure --host=x86_64-w64-mingw32.shared
make install

It all works very nicely, but I later found that something wasn't quite right. When building iverilog-vpi.exe, the flow automatically generates config.h, assuming that the compiler that will be used on the host machine is going to be the same as the compiler that is used on the build machine:

#define IVERILOG_VPI_CC        "x86_64-w64-mingw32.shared-gcc"
#define IVERILOG_VPI_CXX       "x86_64-w64-mingw32.shared-g++"

The effect is that when executing iverilog-vpi.exe, it fails due to being 'unable to locate MinGW'. To solve the problem, I manually edited driver-vpi/config.h as follows and did a make install again:

#define IVERILOG_VPI_CC        "gcc"
#define IVERILOG_VPI_CXX       "g++"

I'm not familiar enough with autoconf to address this issue in a nice and clean way, but it would be nice if someone could look into this !

Having solved this first issue, I then decided to install myhld and install co-simulation support as described in https://github.com/myhdl/myhdl/blob/master/cosimulation/icarus/README.txt

The first step is to build myhdl.vpi simply by doing make. That didn't work.

Looking into the details, I seem to have found an issue in the source code of iverilog-vpi.exe. I'm not sure if this issue is real, and perhaps it's only revealed when cross-compiling (but not when compiling natively with Msys) The list of source files passed to iverilog-vpi.exe is myhdl.c myhdl_table.c. However, while the first source file is correctly parsed as myhdl.c, the corresponding object file is generated as myhdl.c myhdl_table.o. It eventually leads to the error below:

gcc: fatal error: input file 'myhdl.c' is the same as output file

From what I can tell, it all comes down to a few lines in driver-vpi/main.c :

         /* Build the object file name */
        ostart = strrchr(ptr1, '/');
        if (ostart == NULL) ostart = ptr1;
        else ostart += 1;
        olen = strrchr(ptr1, '.') - ostart;
        assignn(&obj, ostart, olen);
        append(&obj, ".o");

I could be wrong, but it seems that all is required to fix the issue is to replace ptr1 with src. Et voila ! Can anyone confirm ?

[DavidC-75]

The first step is to build myhdl.vpi simply by doing make. That didn't work.

Looking into the details, I seem to have found an issue in the source code of iverilog-vpi.exe. I'm not sure if this issue is real, and perhaps it's only revealed when cross-compiling (but not when compiling natively with Msys)

I just tried building myhdl.vpi using the Icarus binaries for windows from https://bleyer.org/icarus/ The behavior is exactly the same, so it's not just an artefact of cross-compiling and it looks like a real bug in driver-vpi/main.c

[steveicarus]

I do not have a Windows machine to work on this issue. It's probably not a super hard issue to address, but it needs the touch of a Windows programmer with the appropriate resources.

There seem to be two issues:

1. When cross compiling, configuration selects the cross compiler for the generated iverilog-vpi.exe to use, meaning it can't run natively. It really should generate the native name for the compiler. And,
2. Independent of cross compiling, there may be a problem generating the compile command line. Notably, there are reports that the name of the generated object file is somehow messed up.

This would be a good first issue foe someone who is not super into the depths of the Verilog compiler, since this just deals with the front end.

[DavidC-75]

Thanks for that fix, really appreciated !

[martinwhitaker]

iverilog-vpi is fixed in both the master and v11 branches. I'm not planning to work on cross-compiling issues.