Is there anything better than setting LD_LIBRARY_PATH for libXaw.so.7: cannot open shared object file?

General support questions
Post Reply
DrDave
Posts: 49
Joined: 2020/03/12 10:23:33

Is there anything better than setting LD_LIBRARY_PATH for libXaw.so.7: cannot open shared object file?

Post by DrDave » 2020/04/01 20:02:28

I'm trying to run an application IBM Bootable Media Creator (BoMC)

https://www.ibm.com/support/pages/ibm-b ... eator-bomc

which hopefully will allow me to update the firmware on my IBM X3650 M4. I'm running into this problem:

Code: Select all

/tmp/portable_install_00000001/gui/launchpad/splash/linuxx86/AZY_Splash: error while loading shared libraries: libXaw.so.7: cannot open shared object file: No such file or directory
I installed the Xaw3d

Code: Select all

# yum install Xaw3d
(Sorry, I know people say one should use sudo, but I've never had problems using root for decades on Solaris - sudo just seems an annoyance to me!)

which I think puts the libraries in /usr/lib64. Maybe they were there before tryin to install them, but I don't think so.

If I set LD_LIBRARY_PATH to /usr/lib64, then that error goes away, but I get errors about the wrong ELFCLASS, so I'm not sure that achieved anything useful.

Whoever
Posts: 1361
Joined: 2013/09/06 03:12:10

Re: Is there anything better than setting LD_LIBRARY_PATH for libXaw.so.7: cannot open shared object file?

Post by Whoever » 2020/04/02 01:34:27

DrDave wrote:
2020/04/01 20:02:28
If I set LD_LIBRARY_PATH to /usr/lib64, then that error goes away, but I get errors about the wrong ELFCLASS, so I'm not sure that achieved anything useful.
This suggests that you have a directory in your LD_LIBRARY_PATH that is causing problems. /usr/lib64 should be searched by default.

What does

Code: Select all

echo $LD_LIBRARY_PATH
show in a shell in which you have not already reset LD_LIBRARY_PATH?

DrDave
Posts: 49
Joined: 2020/03/12 10:23:33

Re: Is there anything better than setting LD_LIBRARY_PATH for libXaw.so.7: cannot open shared object file?

Post by DrDave » 2020/04/02 06:38:59

Although I have not tried it yet, I believe someone sussed the problem on this thread.

viewtopic.php?f=13&t=73911

The 64-bit executable is self extracting, and would appear to be extracting a 32-bit executable. So I need the 32-bit libraries, despite the executable I downloaded from the IBM website is 64-bit. I am surprised IBM did that.

User avatar
jlehtone
Posts: 4531
Joined: 2007/12/11 08:17:33
Location: Finland

Re: Is there anything better than setting LD_LIBRARY_PATH for libXaw.so.7: cannot open shared object file?

Post by jlehtone » 2020/04/02 09:50:51

DrDave wrote:
2020/04/02 06:38:59
The 64-bit executable is self extracting, and would appear to be extracting a 32-bit executable. So I need the 32-bit libraries, despite the executable I downloaded from the IBM website is 64-bit. I am surprised IBM did that.
"Installer" and "application" are separate entities.

MS Windows (at least used to) has no package management like Linux distros. Every application has its own installer (and often update service too). A There was no sense to reinvent to wheel, so many companies used same (commercial?) installer. Very popular installer was a 16-bit program. It became unusable with 64-bit Windows that has no 16-bit subsystem.

Commercial applications for Linux tend to follow the same idiom. Either the practice is copied from Windows, company does not want to maintain their product for multiple Linux package managers, or whatnot. You get compressed content and installer that extracts content to some directory. Content and installer can be in one file. The installer does not really have any ties to the content. It just gets a list of files to extract, etc. (To require 32-bit Java to install a 64-bit non-Java program is not my idea of fun.)

Sounds like IBM has updated their tooling to use 64-bit installer for all their applications. The content in your case is some 32-bit application. Something older, that IBM sees no need to recompile as 64-bit? Or perhaps applications targets (used to) have 32-bit subsystem by default?

DrDave
Posts: 49
Joined: 2020/03/12 10:23:33

Re: Is there anything better than setting LD_LIBRARY_PATH for libXaw.so.7: cannot open shared object file?

Post by DrDave » 2020/04/02 10:35:36

The strange thing is, I can download a 32-bit version of the application, which I assume uses a 32-but installer. So why does IBM not create just one package that works on 32-bit & 64-but system?

The manual for the software makes no reference to the need to install any libraries whatsoever. What the manual does do, which worries me a little, is imply, to (my limited knowledge at least), it only works on certain releases of Redhat 4, 5, 6 and 7. In the case of Redhat 6, there’s some implication it works with releases 1, 2, 3 and 5, with no mention of 4, 6, 7, 8, 9 or 10. See my earlier post that shows a copy of the supported operating systems.

User avatar
jlehtone
Posts: 4531
Joined: 2007/12/11 08:17:33
Location: Finland

Re: Is there anything better than setting LD_LIBRARY_PATH for libXaw.so.7: cannot open shared object file?

Post by jlehtone » 2020/04/05 19:21:39

Vendors tend to list only the OS versions that they have tested their product with in order to avoid liability.

On page that you did link:
Version 9.61: Jul. 2014
Latest version was published way before later point updates existed.

DrDave
Posts: 49
Joined: 2020/03/12 10:23:33

Re: Is there anything better than setting LD_LIBRARY_PATH for libXaw.so.7: cannot open shared object file?

Post by DrDave » 2020/04/05 19:48:26

Thank you.

I'm still having issues with getting this server updated, but I will not bore you with all the problems. :)

Post Reply