Categories
Engineering FPGA Hardware Linux

Xilinx ISE 14.7 and SDK on Ubuntu 22.04

As discussed in [Insanity4004]’s excellent blog post, Xilinx packages their ISE and SDK suite with the necessary libraries (like Qt4 for example). Unfortunately, some seem to be missing and cause errors that are rather cryptic for the lay(wo)man.

In addition to providing libpng and libfreetype, I’ve noticed that in order to start the SDK (xsdk, part of the EDK package), you need to provide an older version of libcairo as well.

With the standard installation, starting xsdk results in:

[...]/EDK/bin/lin64 $ ./xsdk

  Xilinx Software Development Kit
  Xilinx EDK 14.7 Build EDK_P.20131013
  Copyright (c) 1995-2012 Xilinx, Inc.  All rights reserved.
  Eclipse:
  An error has occurred. See the log file
  [...]/.eclipse/com.xilinx.sdk.product_1.0.0_1005998729/configuration/1655967348948.log.

[...]/EDK/bin/lin64 $ cat [...]/.eclipse/com.xilinx.sdk.product_1.0.0_1005998729/configuration/1655967348948.log

  !SESSION 2022-06-23 08:55:48.743 -----------------------------------------------
  eclipse.buildId=Release 14.7 Build SDK_P.20131013
  java.version=1.6.0_21
  java.vendor=Sun Microsystems Inc.
  BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=de_DE
  Command-line arguments:  -os linux -ws gtk -arch x86_64
  
  !ENTRY org.eclipse.osgi 4 0 2022-mm-dd hh:mm:ss.605
  !MESSAGE Application error
  !STACK 1
  java.lang.UnsatisfiedLinkError: Could not load SWT library. Reasons: 
          [...]/.eclipse/com.xilinx.sdk.product_1.0.0_1005998729/configuration/org.eclipse.osgi/bundles/243/1/.cp/libswt-pi-gtk-3836.so: /lib/x86_64-linux-gnu/libcairo.so.2: undefined symbol: FT_Get_Var_Design_Coordinates
          no swt-pi-gtk in java.library.path
          Can't load library: [...]/.swt/lib/linux/x86_64/libswt-pi-gtk-3836.so
          Can't load library: [...]/.swt/lib/linux/x86_64/libswt-pi-gtk.so
          [...]/.swt/lib/linux/x86_64/libswt-pi-gtk-3836.so: /lib/x86_64-linux-gnu/libcairo.so.2: undefined symbol: FT_Get_Var_Design_Coordinates
  
          at org.eclipse.swt.internal.Library.loadLibrary(Library.java:331)
          at org.eclipse.swt.internal.Library.loadLibrary(Library.java:240)
          at org.eclipse.swt.internal.gtk.OS.<clinit>(OS.java:22)
          at org.eclipse.swt.internal.Converter.wcsToMbcs(Converter.java:63)
          at org.eclipse.swt.internal.Converter.wcsToMbcs(Converter.java:54)
          at org.eclipse.swt.widgets.Display.<clinit>(Display.java:133)
          at org.eclipse.ui.internal.Workbench.createDisplay(Workbench.java:695)
          at org.eclipse.ui.PlatformUI.createDisplay(PlatformUI.java:161)
          at org.eclipse.ui.internal.ide.application.IDEApplication.createDisplay(IDEApplication.java:154)
          at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:96)
          at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196)
          at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110)
          at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79)
          at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:353)
          at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
          at java.lang.reflect.Method.invoke(Unknown Source)
          at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629)
          at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584)
          at org.eclipse.equinox.launcher.Main.run(Main.java:1438)
          at org.eclipse.equinox.launcher.Main.main(Main.java:1414)

The reason is not too hard to find, but the error message is a mouthfull. The important bit is

java.lang.UnsatisfiedLinkError: Could not load SWT library. Reasons: 
 [...]
/lib/x86_64-linux-gnu/libcairo.so.2: undefined symbol: FT_Get_Var_Design_Coordinates

Which basically means: I am looking for libcairo, found it on your system, but the symbol (call, function, whatever) named FT_Get_Var_Design_Coordinates does not exist there.

I have not investigated the reasons for this further. I assume, this function got renamed, moved, dropped since 2013. So I followed the recipe proposed in the blog post mentioned in the beginning:

  • Get the Ubuntu 16.04 deb-file of libcairo (e.g. by searching for “ubuntu 16.04 libcairo” in your favourite search engine)
  • Open it, and open the data.xz file within.
  • Extract the file libcairo.so.2.11400.6
  • Rename it to libcairo.so.2
  • Move it to your [...]/EDK/lib/lin64 folder. In my case this is /opt/Xilinx/14.7/ISE_DS/EDK/lib/lin64.

I fear I might run into these issues again and again since we’re stuck here with a Virtex-6 device. I wonder if SymbiFlow F4PGA are working on a 6-series toolchain. That’d certainly create some resilience against the future.

Small side note I: The 6-series system here is supposed to replace an analogue RF control system that was in service for 30-something years. People were reluctant to switch to digital because of fears of this (what you see above): Toolchains being very complex and not working anymore after only a couple of years, vendors dropping support (well, Xilinx technically did not drop it entirely, but they’ve certainly not fixed library dependencies or checked that they ship their programmes with the old versions).

Small side note II: The fact that I can just (1) go to a trusted repository of old packages (Ubuntu’s Launchpad), (2) grab a package file, (3) extract an old shared library file, and (4) drop it in place without breaking my whole system, is a pretty awesome feature of Linux systems. I know for a fact that other platforms (yeah, looking towards the Seattle area) struggle with steps 1 and 4.

Post scriptum I: Trying to start xilhelp revealed three more libraries missing. libXp.so.6 (get it here), libXm.so.4 (run apt install libxm4) and libstdc++5 (you’ll have to go back to Ubuntu 14.04 Trusty for that). But ended in a SEGFAULT *sigh*.

Post scriptum II: Way more is broken than I had estimated! All Tcl-based scripts (that is: all IP Core generators) need libtcl8.4, obviously, duh! So, well get libtcl8.4.so from Ubuntu 16.04. At least, now the license wizard is opening up. But that causes all sorts of other problems with Tcl. I suppose it’s because no packages are installed in any way. Let’s say: ISE 14.7 is severely broken on newer systems. Way out 1: A VM with Ubuntu 14.04 or 16.04 (yikes!). Way out 2: F4PGA, maybe!?