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?