SCIENTIFIC-LINUX-USERS Archives

June 2017

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Andrew C Aitchison <[log in to unmask]>
Reply To:
Andrew C Aitchison <[log in to unmask]>
Date:
Sat, 24 Jun 2017 17:43:17 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (34 lines)
On Sat, 24 Jun 2017, Larry Linder 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.

On SL6 64bit libraries should be in /usr/lib64/ and 32 bit in /usr/lib/


Does setting LD_LIBRAY_PATH and/or LIBRARY_PATH
t include the directory with these libraries help ?
(Bash: export LD_LIBRARY_PATH=/my/cad/libraries:$LD_LIBRARY_PATH
  T/csh: setenv LD_LIBRARY_PATH /my/cad/libraries:$LD_LIBRARY_PATH  -- IIRC)


> Is there anyway to determine if a lib is 32 bits or 64 bits without
> recompiling sorce and making new libs.

# file /lib*/libc-2*.so
/lib64/libc-2.12.so: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
/lib/libc-2.12.so:   ELF 32-bit LSB shared object, Intel 80386, version 1 (GNU/Linux), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped

If the library is a symbolic link you may need 'file -l' or to give file 
the name of the real file.

-- 
Andre C Aitchison

ATOM RSS1 RSS2