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.]