Wrangling System Generator onto Ubuntu 20.04

A lot of projects from this group use Xilinx’s System Generator tool for hardware description. It sits between Vivado and MATLAB, inheriting the dependencies and system requirements of both.

On my Ubuntu 20.04 box, after hours of installing Vivado 2020.1 and MATLAB R2020a, System Generator would refuse to open any designs.

Here’s a link to a relaxing Bob Ross video, just in case you’re in the same situation.

Symptoms

Clicking to open any model would crash and show this error in the MATLAB command window:

Caught "std::exception" Exception message is: /lib/x86_64-linux-gnu/libhogweed.so.5: undefined symbol: __gmpn_cnd_sub_n: Success: Success

I managed to get it working, so want to make this post for two reasons.

Document what the fix is — helping other frustrated FPGA folks in the short term
Show how I debugged it — teaching you to fish (for solutions to EDA tool Linux incompatibilities)

TL;DR

Vivado brings a conflicting version of libgmp into your environment. You can avoid this by moving them to a different folder.

sdr@strath$ cd $XILINX_VIVADO/lib/lnx64.o/Ubuntu/
sdr@strath$ mkdir exclude
sdr@strath$ mv libgmp.so* exclude/

You’ll also need to install qt4 from a PPA (the official repos only have qt5 now).

sdr@strath$ sudo add-apt-repository ppa:rock-core/qt4
sdr@strath$ sudo apt update
sdr@strath$ sudo apt install libqtcore4 libqtgui4

That’s all. Hopefully you can use System Generator now!

The Debugging Process

This type of issue will often end in one of two ways:

you’ll find an arcane incantation online to solve it blindly, or…
you’ll be stuck with the vendor response “Ubuntu 20.04 is not an officially supported OS. (Please spend a full day reinstalling everything)”.

I need to use these tools for my own research but don’t want that to dictate which OS I use. These sorts of issues will occasionally crop up if you’re as technologically stubborn as me. So how do we go about debugging something like this?

Let’s try to translate the error message:

/lib/x86_64-linux-gnu/libhogweed.so.5: undefined symbol: __gmpn_cnd_sub_n: Success: Success

It’s saying that while running some code in the libhogweed library, it couldn’t find a function __gmpn_cnd_sub_n. That function is most likely from a different library. Either this second library can’t be found, or maybe it is pointing to an unexpected version of the library without this function. The later is a common issue with EDA tools because vendors like to package their software up with lots of older libraries that they control, rather than the more typical Linux approach of using system libraries controlled by the package manager. We’ll often get into a situation where a system library has a dependency that is satisfied by the package manager but the EDA tool has kindly injected an older version of it into our environment. If the two versions are incompatible, we have a problem.

We can use ldd to show us the library dependencies a program has. This will show us if any dependencies are missing, or if any are being found in an unusual place. From inside MATLAB (this is important — if you open a new terminal your environment might not be the same) let’s ask about libhogweed’s dependencies.

>> !ldd /lib/x86_64-linux-gnu/libhogweed.so.5
	linux-vdso.so.1 (0x00007ffcfbae1000)
	libnettle.so.7 => /lib/x86_64-linux-gnu/libnettle.so.7 (0x00007f4770bce000)
	libgmp.so.10 => /home/craig/tools/Xilinx/Vivado/2020.1/lib/lnx64.o/Ubuntu/libgmp.so.10 (0x00007f4770941000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f477074f000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f4770c64000)

This is showing us that all but one library is from the system /lib/ folder. The odd one out is libgmp which is being sourced from Vivado’s own stash of libraries. So, our system version of libhogweed is trying to call a function from libgmp, but it’s not pointing to the correct version and it fails to find the function.

The easiest way to ignore one of these libraries bundled with Vivado is to move it into a different folder. This removes it from our library path but keeps it around on disk in case we need to restore it.

sdr@strath$ cd $XILINX_VIVADO/lib/lnx64.o/Ubuntu/
sdr@strath$ mkdir exclude
sdr@strath$ mv libgmp.so* exclude/

Obviously there might be other consequences for hiding this library from Vivado, but we can always restore it after doing our System Generator work.

Now our original error should disappear but things still aren’t quite right. After trying to load a model MATLAB will have a long hard think to itself before opening Simulink and reporting this warning:

Warning: The System Generator GUI socket server timedout while waiting for an incoming socket connection. To tune the acceptTimeout value in the xlServerSocketOptions.m file. The xlServerSocketOptions.m file is on your MATLAB path and can be edited by typing 'edit xlServerSocketOptions.m' in the MATLAB console.

Although Simulink has opened, strange things will happen when interacting with anything System Generator specific. For example, let’s just try to double click a simple block and change it’s properties.

Hmm. From a bit of googling, this is sounds like the default behaviour when System Generator has simply not started up but we make it into Simulink regardless. The warning hints at this as well. Let’s try to find out why sysgen hasn’t started up.

We’ll try to find out where the sysgen program lives with the which command.

sdr@strath$ which sysgen
/home/craig/tools/Xilinx//Vivado/2020.1/bin/sysgen

The next step would be to use ldd to check for missing dependencies. However, this sysgen file isn’t actually a binary program so ldd will fail. The file is actually just a huge bash script that sources various things and sets up our environment before launching the real, honest to goodness binary.

So where’s the real binary? Let’s use find and assume it is 1) a file, 2) an executable file, and 3) has “sysgen” somewhere in its name.

sdr@strath$ cd $XILINX_VIVADO
sdr@strath$ find . -executable -type f -name '*sysgen*'
./examples/sysgen_demos/sysgenFSE_PreLoadFcn.m
./bin/unwrapped/lnx64.o/sysgensockgui
./bin/sysgen
...

I’ve omitted a few entries here, but the one we’re looking for appears to be ./bin/unwrapped/lnx64.o/sysgensockgui. Apart from the bash script, this is the only match in the bin/ folder.

Let’s check it with ldd.

sdr@strath$ ldd ./bin/unwrapped/lnx64.o/sysgensockgui
	linux-vdso.so.1 (0x00007fff435fe000)
	libQtCore.so.4 => not found
	libQtGui.so.4 => not found
	libQtNetwork.so.4 => not found
	libQtXml.so.4 => not found
	librdi_itlib.so => not found
	libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fec76fb5000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fec76e64000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fec76e49000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fec76c57000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fec771ba000)

A ha! It’s missing some qt4 libraries! This is a bit awkward because Ubuntu 20.04 only has qt5 in its official repos. If you’re comfortable using PPAs that random blogs suggest, go ahead and install qt4 like so:

sdr@strath$ sudo add-apt-repository ppa:rock-core/qt4
sdr@strath$ sudo apt update
sdr@strath$ sudo apt install libqtcore4 libqtgui4

And that’s us! System generator seems to run OK now, and we’ve met some tools to help us fix similar issues the next time you upgrade OS.

🥳