On 07/16/2012 10:59 PM, eigenroot wrote: > Hi everyone, > > I am wondering if anyone here use HFSS on Linux. After installation in > my Scientific Linux 6 x86_64, there were errors when I launched this > program: > > ######################################################## > ### Warning: Unable to determine Red Hat Enterprise Linux version number. > > Currently-supported Linux versions include: > - Red Hat Enterprise Linux v4 and v5 (both 64-bit PC) > - SuSE Linux Enterprise Server 10 and 11 (both 64-bit PC) > HFSS 14.0 Product Configuration > =============================== > > > Running first-time configuration... > - Verifying all software dependencies are available: ERROR > > * The following dependencies were not found: > libbz2.so.1 > > Full ldd output is available at: /tmp/in1xMQLcA9.Ansoft.Dependencies.log > > *** Error: Not all dependencies were found. *** > ######################################################## > > But I did have packages bzip2-libs and bzip2-devel installed. A "locate > libbz2.so.1" gave > > /lib/libbz2.so.1 > /lib/libbz2.so.1.0.4 > /lib64/libbz2.so.1 > /lib64/libbz2.so.1.0.4 > > If looking into the log file, > "cat /tmp/in1xMQLcA9.Ansoft.Dependencies.log | grep libbz2.so.1" gave > > libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f307df33000) > libbz2.so.1 => not found > > I also tried "ln -s /lib64/libbz2.so.1 /usr/lib/libbz2.so.1", but HFSS > still couldn't find the library. > > Can anyone give some hints? Thanks~! Most likely the installer is trying to determine your version from a combination of a uname query and the contents of /etc/redhat-release. Your package is telling you it is checking for v4 and v5 so SL 6, being based on RHEL 6, will not match. In addition, if it cares about the contents of /etc/redhat-release then it would miss anyway because that file says "Scientific Linux" not "Red Hat Enterprise Linux"; not many scripts check this file in depth because of how flimsy compatibility checks based on it are, but I've seen this before more than once. If the program loader is a script (shell, Python, Perl, etc.) it would be pretty easy to read it and see where/why it is failing, and adjust it to accept your system. If it the loader itself is black boxed (that is, a binary-only release of compiled language code, like the rest of HFSS, I believe) then you might be stuck needing SL 5 for it to run*. As far as the lib dependency, it may be looking for a specific signature, not just the path. I'm not sure what resolution would entail or if resolving the lib dependency would permit the program to execute and merely give a RHEL version number warning. You have enough detail here to ask Ansys about it directly, though. Hopefully this illuminated more than it confused. [* Or you could try using an aliased uname shell function in a separate environment (like chroot execution) to give a false result that looks like what RHEL 5 would return to try tricking it into running, but this could be a path to madness without knowing exactly how the system compatibility check is happening and what part of is failing.]