Unofficial support for Synopsys Sentaraus TCAD (through EUROPRACTICE)

English Applications
1

Hello,

I will first let you know that I have been documenting and writing some offline packages to make my computers to work on OpenSUSE, I make these available for some of my colleagues and students. I am an unofficial developer for my community.

Recently, my current institute subscribed to some software provided through EUROPRACTICE. This thread is about supporting the software Synopsys Sentarus TCAD. This software is officially not supported on OpenSUSE, but it is supported on some older versions RHEL and SLES, and with minor modifications I was able to get it to work.

As long as I will be using this software, I will be supporting it unofficially. I am starting the thread here for personal reference as well as for others.

0.As far as installation of TCAD. Microelectronics at EUROPRACTICE provides an easy installation package as well as instructions to use the installation script provided by Synopsys. Following these instructions, you can install the package without much problem. OpenSUSE is based on Red Hat, I use the RHEL package.

Now onto issues on OpenSUSE LEAP 15.0 KDE (tested on LEAP 42.3 KDE and LEAP 15.1 KDE as well). Starting with a problem and then the solution.

  1. OpenSUSE does not have libcrypto.so.10
    When you try to start Synopsys visual/process executables, you will get something like this
/eda/synopsys/2018-19/RHELx86/SENTAURUS_2018.06-SP2/tcad/O-2018.06-SP2/linux64/bin/sprocess:
error while loading shared libraries: libcrypto.so.10: cannot open shared object file: No such file or directory

Upon a little bit of research, libcrypto.so.10 is actually identical to libcrypto.so.1.0.0 provided with libssl.so.1.0.0 unfortunately just following a symbolic link below doesn’t work.

sudo ln -s /usr/lib64/libcrypto.so.1.0.0 /usr/lib64/libcrypto.so.10

and it will yield the following error messages:

/eda/synopsys/2018-19/RHELx86/SENTAURUS_2018.06-SP2/tcad/O-2018.06-SP2/linux64/lib/svisual_exec:
/usr/lib64/libcrypto.so.10: version `libcrypto.so.10' not found (required by
/eda/synopsys/2018-19/RHELx86/SENTAURUS_2018.06-SP2/tcad/O-2018.06-SP2/linux64/lib/svisual_exec)

/eda/synopsys/2018-19/RHELx86/SENTAURUS_2018.06-SP2/tcad/O-2018.06-SP2/linux64/lib/svisual_exec: 
/eda/synopsys/2018-19/RHELx86/SENTAURUS_2018.06-SP2/tcad/O-2018.06-SP2/linux64/lib/libz.so.1: 
version `ZLIB_1.2.9' not found (required by /usr/lib64/libpng16.so.16)

It seems that relabeling is inadequate, it really does need this specific package. In my case, since I have access to a server with RHEL6 and 7 installed I borrowed a compiled library.

libcrypto.so.1.0.1e

This solved 1.

  1. I was able to eliminate libz issue by providing a symbollic link to my system’s libz.so.1 to the TCAD library packages.
mv /eda/synopsys/2018-19/RHELx86/SENTAURUS_2018.06-SP2/tcad/O-2018.06-SP2/linux64/lib/libz.so.1 /eda/synopsys/2018-19/RHELx86/SENTAURUS_2018.06-SP2/tcad/O-2018.06-SP2/linux64/lib/libz.so.1.back
ln -s /lib64/libz.so.1 /eda/synopsys/2018-19/RHELx86/SENTAURUS_2018.06-SP2/tcad/O-2018.06-SP2/linux64/lib/libz.so.1

This solved 2.

Lastly, the environmental variable to point at the license server is SNPSLMD_LICENSE_FILE instead of SNPS_LICENSE_FILE.

2

I forgot to mention the steps I installed libssl and libcrypto as the following:

sudo zypper in libssl45*

and in the latest OpenSUSE LEAP 15.1 I use a newer package instead of libcrypto.so.1.0.0 as the symbollic link, I setup:

sudo ln -s /usr/lib64/libcrypto.so.1.1 /usr/lib64/libcrypto.so.10
3

Another potential issue is when the application cannot find libtinfo.so.5

This is provided by libncurses

sudo zypper in libncurses*
4

Another issue is for computers with NVIDIA installed, there will be a conflict between nouveau and Nvidia, this is quickly resolved if by deleting xf86-video-nouveau

sudo zypper rm xf86-video-nouveau
5

I just had a bit of dumb moment where I realized when I opened the Sentarus Structure Editor and by no means load the toolbars! After believing that it must be an issue with libqt, for some reason the settings for my sde has been set to show no tool bars. It also turns out that the way to restore all of the toolbar is to use editor’s default GUI.

I’ve added an alias


alias sde="sde -defaultGUI"

in my .bashrc

6

In order to run the icwbev interface with TCAD, you also need the libpng12-0 package

sudo zypper in libpng12-0

Furthermore, similar to TCAD, I gave a symbollic link for ICWBEV.


mv /eda/synopsys/2018-19/RHELx86/ICWB-EV-PLUS_2018.06-SP2/lib/linux64/libz.so.1 /eda/synopsys/2018-19/RHELx86/ICWB-EV-PLUS_2018.06-SP2/lib/linux64/libz.so.1.back
ln -s /lib64/libz.so.1 /eda/synopsys/2018-19/RHELx86/ICWB-EV-PLUS_2018.06-SP2/lib/linux64/libz.so.1
7

If you move the real location of your library file, your package manager won’t be able to find it when an update is released.

Better to leave the library file in its original location and create your symlink accordingly.

TSU

8

Hello Tsu, I am already doing that

mv /eda/synopsys/2018-19/RHELx86/ICWB-EV-PLUS_2018.06-SP2/lib/linux64/libz.so.1 /eda/synopsys/2018-19/RHELx86/ICWB-EV-PLUS_2018.06-SP2/lib/linux64/libz.so.1.back
ln -s /lib64/libz.so.1 /eda/synopsys/2018-19/RHELx86/ICWB-EV-PLUS_2018.06-SP2/lib/linux64/libz.so.1

/eda/synopsys/2018-19/RHELx86/ICWB-EV-PLUS_2018.06-SP2/lib/linux64

is the directory of the library of the software package which gets updated once a year or so, I am relabeling it as a backup just in case, and sending a symbollic link from my system

ln -s /lib64/libz.so.1 /eda/synopsys/2018-19/RHELx86/ICWB-EV-PLUS_2018.06-SP2/lib/linux64/libz.so.1
9

A small version conflict for libz has been found and can be resolved by the following:

cp /eda/synopsys/2018-19/RHELx86/SENTAURUS_2018.06-SP2/tcad/O-2018.06-SP2/linux64/lib/gds2tcadLib/libz.so.1 /eda/synopsys/2018-19/RHELx86/SENTAURUS_2018.06-SP2/tcad/O-2018.06-SP2/linux64/lib/gds2tcadLib/libz.so.1.back
ln -sf /usr/lib64/libz.so /eda/synopsys/2018-19/RHELx86/SENTAURUS_2018.06-SP2/tcad/O-2018.06-SP2/linux64/lib/gds2tcadLib/libz.so.1
10

Hi,
Reviewing your steps,
Some observations…

If you wish to create a reference, and in particular something you can update (corrections, additions, different openSUSE versions),
I’d recommend you create a Wiki page either for everything you might do or a specific purpose. So, for instance you can view my Wiki which is a collection of various “How Tos” for both my own and others’ use. If you’d like to create an official SDB page, open an SDB page and model your page URL on an existing… See my signature at the bottom of this post for steps how to start your own Wiki, and my Wiki can be found at

https://en.opensuse.org/User:Tsu2

First, I don’t know if an RPM is available for Fedora instead of RHEL, if one is available you might find the OS file tree is a bit closer and might avoid some issues, otherwise the RHEL RPM you’re using can work…

Inspecting your first issue about libcripto.so.10, actually the symlink should work fine…
The package install fails only because the symlink isn’t followed during the package **installation **only, but if you “ignore” the error, you should find the app will functionally find the symlinked libarary and have no problems.
So, no need to “borrow” the file from somewhere else.

When you use a wildcard Regular Expression (the asterisk in libncurses* and libssl145*), it’s good practice to enclose in single quotes (preferred) or double quotes (should work) to avoid unintended “expansion.” Expansion won’t always happen, but using proper syntax as SOP can avoid unnecessary troubleshooting problems.

When you write something for public and not only personal use, you sometimes have to think about writing about more than what you’ve done or more completely. When you describe uninstalling (why not blacklisting so you have flexibility?) due to your proprietary nVidia driver, you should include at least a link to the install method you used. I’m under the impression the various official guides to installing the nVidia driver blacklist nouveau so you shouldn’t have a conflict.

Keep in mind your modification to modify your bashrc will apply only to your logged in User. If you intend your app to be used by multiple Users or even at least both your User and root, you should instead load your command into a file /etc/profile.local instead.

HTH,
TSU

11

Hello TSU,
I will create my own wiki page as suggested.

Regarding libcripto, the issue is due to the fact I am using a pre-compiled compressed package provided by the supplier. I don’t actually “install” the software, rather un-compress the package using the “install package”. I chose this option although it is not the best, because this is not my full time duties. The point for me is to make it work, compatible for personal and community use if referenced.

I agree the wildcard can be dangerous, and can self-conflict.

Nouveau was blacklisted from /etc/modprobe.d/ but when some of the proprietary tools are launched, they immediately try to load nouveau package and hangs for a few seconds. The installation method/procedure has been written in another thread, but I find that it’s irrelevant as there is nothing wrong if nouveau is used as long as Nvidia isn’t installed.

Yes, modifying in bashrc would only affect the single user, but I wrote this in perspective as a user. I am not an official administrator/IT. I am a user and I am writing for the benefit of a user. I will explore the local profile, but I wish to leave everything unloaded by default for super and other users as there are limited number of licenses, and I want to make sure I have a tight grip on who is using the tool.

Thank you for your pointers.
-SJL

12

sudo zypper in libncurses*should instead be

sudo zypper in libncurses5