Running older Altera Quartus on modern 64bit GNU/Linux

While recent (as of the time of writing – 20.x) versions of Quartus install and run on current GNU/Linux distributions (DISCLAIMER: Ubuntu/Xubuntu tested – don’t hold me accountable for what your distribution of choice does), there are still valid use cases for running an older version. Among them:

  • you target the venerable, 5V logic capable MAX 3000/7000 series instead of the 3.3/1.8/0.x Volt rubbish, and the latest version officially supporting them is 13.0 (not even 13.1)
  • the newer, better, improved and enhanced versions are no longer able to compile/synthesise/fit your design that worked flawlessly until you changed the Quartus software to a newer, better, improved version…

Well – no problem, let’s install the good-old Quartus II v13.0. The latest (13.0.1.232) should still be available under

https://fpgasoftware.intel.com/13.0sp1/

You go through all the registration nuisance or you just log-in if you still have your old credentials (which may or may not work after Altera was taken over by Intel) and you download the “tarball” package. All nice and dandy. Time to do the actual install. Unpack the tar archive, run the install script, click through questions – defaults are reasonable but you may want to adjust the destination folder for example – and after some time of unpacking the whole beast you should be presented with typical Windows-like options of “creating another stupid desktop shortcut icon”, which is a sign of success. The choice of running the installed software is pretty much useless at this moment so you can safely uncheck both and finish the wizard.

You may want to adjust your $PATH variable to include the quartus/bin subdirectory of the installation directory (although I use aliases with absolute paths as described below) and try running Quartus

$ quartus
quartus: error while loading shared libraries: libpng12.so.0: cannot open shared object file: No such file or directory

That’s not what you expected, is it? Erm.. well.. since you are here reading this text then you have most probably already encountered this message. Obviously the very much requested 1.2 version of libpng is long gone with the wind. As of the time of writing the old Ubuntu package can still be downloaded from:

http://security.ubuntu.com/ubuntu/pool/main/libp/libpng/libpng12-0_1.2.54-1ubuntu1.1_amd64.deb

No, simply installing it on current (18.04LTS, 20.04LTS, ..) is not going to work due to changes in the system directories structure introduced after the package was… hm.. “packed” , I guess. Instead of trying to install it I’d rather suggest you to unarchive it:

$ dpkg-deb -xv libpng12-0_1.2.54-1ubuntu1.1_amd64.deb ./

Should give you two folders named lib and usr. Ignore the usr and focus on the lib – copy its content to /lib, which should be linked to /usr/lib

$ sudo cp -a lib/x86_64-linux-gnu/libpng12.so.0* /lib/x86_64-linux-gnu/

you may also copy the docs for completeness. Something like:

sudo cp -a usr/share/doc/libpng12-0 /usr/share/doc

and adjust the ownership of all copied files, but both of those last two actions are not necessary if all we want is to run Quartus II in its glorious 13.0.1.232 version.

OK – all copied, and if you are tempted to declare victory at this moment, then you might be off for an unpleasant surprise when running $ quartus returns:

quartus: error while loading shared libraries: libpng12.so.0: cannot open shared object file: No such file or directory

again. Rest assured that this is the last stronghold of the enemy though. The final blow can be expedited in one of two forms:

$ quartus --64bit

or

$ QUARTUS_64BIT=1 quartus

I have several versions installed and my choice was to add a few aliases like:

alias q13='<V13INSTALLATION_DIR>/quartus/bin/quartus --64bit'
alias q18='<V18INSTALLATION_DIR>/quartus/bin/quartus'
alias q20='<V20INSTALLATION_DIR>/quartus/bin/quartus'

but you choose your weapon yourself.

P. S. As you might have noticed – the Version 18.x (Quartus Prime now) no longer needs the “64bit” flag/envar. Note that this does not mean that it won’t ask for the long outdated libpng. With version 20 there is no longer need for the extra library.

This entry was posted in GNU/Linux, VHDL and tagged , , , , , , . Bookmark the permalink.

Leave a comment