iverilog is missing content from oss-cad-suite/include/iverilog/**

[dlmiles]

After a regular iverilog autoconfig/configure/make/make install, the following files are installed:

# find /usr/local/include/iverilog/
/usr/local/include/iverilog/
/usr/local/include/iverilog/veriuser.h
/usr/local/include/iverilog/sv_vpi_user.h
/usr/local/include/iverilog/_pli_types.h
/usr/local/include/iverilog/acc_user.h
/usr/local/include/iverilog/vpi_user.h
/usr/local/include/iverilog/ivl_target.h

# # find /usr/local/lib/*a
/usr/local/lib/libveriuser.a
/usr/local/lib/libvpi.a

The files DO NOT seem present in CI here, also no files :

https://github.com/YosysHQ/oss-cad-suite-build/actions/runs/5019966822/jobs/9001318938#step:25:5

So they are not present in the output tgz file:

tar -ztvf oss-cad-suite-linux-x64-20230519.tgz  | grep include/iverilog

The tree that is present is:

$ tar -ztvf oss-cad-suite-linux-x64-20230519.tgz  | grep include/py | grep "/$"
drwxr-xr-x root/root         0 2022-11-15 18:06 oss-cad-suite/lib/python3.8/site-packages/include/pygobject-3.0/
drwxr-xr-x root/root         0 2022-06-03 08:49 oss-cad-suite/include/python3.8/
drwxr-xr-x root/root         0 2022-06-03 08:49 oss-cad-suite/include/python3.8/internal/
drwxr-xr-x root/root         0 2022-06-03 08:49 oss-cad-suite/include/python3.8/cpython/

[dlmiles]

# cp -av usr/local/include/iverilog /opt/oss-cad-suite/include/
'usr/local/include/iverilog' -> '/opt/oss-cad-suite/include/iverilog'
'usr/local/include/iverilog/veriuser.h' -> '/opt/oss-cad-suite/include/iverilog/veriuser.h'
'usr/local/include/iverilog/sv_vpi_user.h' -> '/opt/oss-cad-suite/include/iverilog/sv_vpi_user.h'
'usr/local/include/iverilog/_pli_types.h' -> '/opt/oss-cad-suite/include/iverilog/_pli_types.h'
'usr/local/include/iverilog/acc_user.h' -> '/opt/oss-cad-suite/include/iverilog/acc_user.h'
'usr/local/include/iverilog/vpi_user.h' -> '/opt/oss-cad-suite/include/iverilog/vpi_user.h'
'usr/local/include/iverilog/ivl_target.h' -> '/opt/oss-cad-suite/include/iverilog/ivl_target.h'

# cp -v usr/local/lib/*.a /opt/oss-cad-suite/lib/
'usr/local/lib/libveriuser.a' -> '/opt/oss-cad-suite/lib/libveriuser.a'
'usr/local/lib/libvpi.a' -> '/opt/oss-cad-suite/lib/libvpi.a'

So for iverilog the files can be placed into:

oss-cad-suite/include/iverilog/
oss-cad-suite/lib/

Local unit test / VPI simulation of the project here is now working using VPI. So the procedure here is the one that worked for me.

[64]

Looks like these files are deliberately removed? https://github.com/YosysHQ/oss-cad-suite-build/blob/36bb3fe7b03543e791483da52e33d2f1ff1f7485/default/scripts/iverilog.sh#L5

[mmicko]

Reason why they are removed is that you can not reliably build plugins for iverilog using these files. Note that, depending of your host OS version, it could work but also will not in most cases. Same problem is there for other software we include (yosys iteself as well) but for Yosys we provide a way how to reliably compile plugins. Note that issues are related to glibc differences but also additional library dependencies between host system and one on which tools are built that will later cause issues loading actual plugins.

[dlmiles]

Can you cite a specific example of such differences ? It is usual to use an older linux system for linking the release distribution of binaries, many enterprises have for decades now been able to supply reliable Linux binaries that will work on a very wide range of hosts at runtime.

The "manylinux" project exists as a modern day form of a collective understanding on the issues addressing this area of release management of commercial Linux products.

So I am interested in the specifics about this claim and yosys oss-cad-suite. Glibc/stdc++/gcc are distributed with versioned symbols, this will setup a floor in the version allowed (the oldest GLIBC possible at runtime) but any new version will work.

Maybe there is a specific concern related to EDA (such as VPI DSOs or other similar things), but please state the specific of the technical concern.

Thanks

[64]

It seems like one problem comes from oss-cad-suite bundling its own copy of glibc, which all programs link against. This means that when you compile a VPI plugin against a newer version of libc, and then dlopen it from the iverilog program (linked against older libc), it complains because it's loading a library that links against verisoned glibc symbols that are too new.

Not too sure how to proceed, but I'll close the PR as clearly this won't work (in the general case).

[dlmiles]

This is not a valid reason to not distribute the header files and DSOs.

This is easily worked around by users with a docker container and is a well understood and anticipated problem.

An example of a valid reason to not distribute, would be that the plugin loads and appears to work, but crashes, because of something esoteric and magical and something unknown until after maybe hours of simulation. But if the plugin fails to load unfront, due to version mismatches that is working as designed and the user of oss-cad-suite is informed immediately it won't work, by the errors trying to load.

The user can then simply use a docker container to link their DSO with a copy old enough to also be compatible. All oss-cad-suite needs to do to help here is publish the version symbol versions supported. This can be obtained via the build process with a script, evaluating the DSOs (maybe rpm's tooling can provide information), then this added to the release notes automatically from each build. But to be honest, that is something a sufficiently skilled user can do themselves (retrospectively find out what version they are using and what version the target process the DSO is being loaded into is using).

If oss-cad-suite was able to perform the entire build on a "manylinux" base system (not Ubuntu-latest-bleedingedge) then you will observe it very difficult to find a user that experiences the problem in the first place.

[mmicko]

@dlmiles your observations are correct.

Will take care of this and check other pakages as well. We are moving soon to docker image based on Ubuntu 22.04 (work already done on branch) so will prepare document how to build iverilog plugins as well.

[dlmiles]

I meant to say in last paragraph (a correction provided here): If plugin (yosys/VPI/simulation/etc...) creators are able to perform their plugin build on a "manylinux" base system (not Ubuntu-latest-bleedingedge) then you will observe it very difficult to experiences the problem in the first place.

So yes having oss-cad-suite itself as docker using latest version of itself and system libraries is good. Also having the users and 3rd party plugin contributors build via more conservative glibc/stdc++ versions is also good.

So ideally 2 docker versions might exist (in a Yosys future, for each new release of Yosys):

• a oss-cad-suite docker runtime that replaces existing tar.gz style deployment for general use, using latest Ubuntu (FWIW Ubuntu 2404 LTS is slated to be an extremely long LTS release and support cycle, maybe as an answer to RHELs popularity in this release management area)

• another docker image, that exists only as a build environment for 3rd party plugin contributors, that it produces output DSOs that should be more compatible with a variety of environments the Yosys suite might be utilized with. This allows 3rd party plugin vendors an official mechanism to build they plugins, using the latest Yosys but with older manylinux style version symbols. So the resulting binaries can be distributed in binary form with confidence of reaching the most. Maybe this would be built by yosys and provide a tar.gz overlay of the SDK parts that can be extracted into the main docker image, and provide environment needed to build and link.

Thanks for for update, I look forward to seeing this area addresses in future versions