On Sat, Jun 24, 2017 at 10:45 AM, Larry Linder <[log in to unmask]> wrote: > As usual we are always behind. > > We own a cad package that runs fine on SL 5.11 but will not run on SL > 6.9. When you run it on 6.9 It complains about missing libs. If you do > a "whereis" on the "the missing lib" - it finds it. > >From what I could get from google searches it apears that the cad > package is using 32 libraries. Is thee any way around this problem. If > I get the 32 bit libs and put them in /usr/lib it would destroy > the /usr/lib libraries that are already present. > Interesting problem. The Cad Package was expensive and it runs > perfectly but we need to move to 6.9. > > Is there anyway to determine if a lib is 32 bits or 64 bits without > recompiling source and making new libs. Not from the name of the library. But the command "file libwhatever.so" on the files for library does a pretty good job of reporting what architecture it's compiled for, if the library is local. And "file cadpackage" should reveal what architecture the CAD package itself was compiled for, which should help reduce that confusion. If I may suggest? If the missing library is a 32-bit version, and it is available built for RHEL 6 and thus Scientific Linux 6, you should be able to find your existing, 64-bit library and do "rpm -qi -f library-file-name". That will indicate what package provides it. Then you should be able to do "yum list | grep package" and see if there is that package, with a 64-bit and 32-bit version. If it's already there, explicitly install the 32-bit version, typically with package name like "libwhatever-[version]-[release].i686" And by the way, "http://rpm.pbone.net" is my friend and I hope will be your friend for finding libraries that are no longer supported upstream for compatibility applicaitons. And also, there's my dirty trick for setting up local compatibility libraries. RHEL, upstream, publishes compatibility tools for newer versions of software by putting them "/opt/rhel/python33", "/opt/rhel/httpd26", and similar segregated software locations. They also publish "enable" scripts that that put the library, bin, and man directories first in your working environment to provide compatibility for programs that need them. So, if you're manually installing this CAD software, which I'm going to guess is autocad: Install it in /opt/autocad/autocad[version]. If you have to install your own versions of other libraries and packages in /opt/libname/libnameversion/, and use wrappers like those from RHEL to enable those alternative package locations. This keeps it out of /usr/local/, which is another place to put them but can lead to very confusing behavior with incompatible, obsolete or updated libraries. It *especially* avoids the problem if the library source installs "libname.so", and might confuse your operating system about what "libname.so" should really point to. > We have MVWare and can install SL 5.11 under it and run cad package > there but it is not the direction we want to go. We still have some SW > that runs under Windows 2000 Professional that way. Been there, done that, you've my sympathies. I had to provide a VMWare environment for SCO OpenServer for some proprietary financial records software, way back when. > The new version of this Cad package is now a vonthly / yearly > subscription and you have to login to their web site to run the new > package. Our internet is down and a slow AT&T service in rural area. > Sometimes we cannot access the Cad Package and work stops. > AT&T now offers a dish connection to cell towers with 300 meg speeds for > $50/mo but not in our area yet. Aarrgh. Yeah, see, that's why many people have given up on Subversion as a source control system. You can't record commits unless you "Talk To The MotherShip". These days, it's also why my cell phone with a data connection is an emergency backup for when my landlord has forgotten to pay the telecom wifi bill and fails to mention their lapse in bill-paying, and wi-fi gets cut off. I'm moving in a few months, but until then, my cell phone is an invaluable failover for work related communications. Do you mean that the CAD package only operates by direct interaction with their hosted service? Or that they require a continously enabled license access, but the software runs locally? Does this CAD vendor *have* a license that allows disconnected operation? I'd definitely talk to them to explain your poor connectivity situation and see if they can help out. > We are looking for a new Cad Package from another vender that we can buy > and not be bled monthly. > > Thank You > Larry Linder What kind of CAD? Maybe some of us know of good vendors?