RE: phantom dependency on LD_LIBRARY_PATH?

["McPherson, Clyde" <Clyde.McPherson@xxxxxxxxxxxxxxxx>]

Tony:
Yes, the LD_LIBRARY_PATH is needed for the dynamic linking of the shared
libraries during runtime. There are several workarounds for a UNIX system. 

1. Copying the SNACC CML and CPDL shared libraries into /usr/lib. (Personal
opinion:This is not very good, I never like putting non-system related
libraries in /usr/lib.) /usr/lib is the default library path.

2. Copying the needed SNACC CML and CPDL shared libraries into
/usr/local/lib. Once you copy the needed libraries into /usr/local/lib, you
will have to modify your LD_LIBRARY_PATH to point to /usr/local/lib, if it
doesn't point there already.

3. Modifying the SNACC CML and CPDL libraries to use static linked
libraries. The CML is designed to use shared libraries, and you may run into
linkage problems if you modify the CML in this way. As far as SNACC, the
making of SNACC I believe already produces a static library, along with a
shared library.

I hope this answers your questions
Tex


> -----Original Message-----
> From: Tony Stein [mailto:astein@xxxxxxx] 
> Sent: Friday, November 02, 2001 2:21 PM
> To: imc-snacc@xxxxxxx; imc-cml@xxxxxxx
> Subject: phantom dependency on LD_LIBRARY_PATH?
> 
> 
> 
> 
>          I've been able to successfully build and run my 
> applications, on 
> Solaris, using the static and dynamic libs for CML and SNACC. At this 
> point, I am trying to eliminate dependency on the LD_LIBRARY_PATH 
> environment variable, by linking the apps with -L and -R 
> flags that point 
> to the libs' locations. Linking works fine, runtime is a problem.
>          My understanding of the situation is that, at 
> runtime, ld.so.1 (or 
> its equivalent) must resolve all symbols before the 
> application will start. 
> Otherwise, the application will quit, with unresolved symbol 
> errors. I 
> encounter the following behavior: The application starts with 
> no complaints 
> from ld.so.1 (i.e. all symbols are resolved just fine). When 
> I attempt to 
> initialize the CML and create a session, it fails, returning 
> an error code 
> of 48 (CM_ASN_DEC_DLL_FAILED) which, I believe, points to a 
> problem loading 
> the SNACC libs. If I add the proper paths to the 
> LD_LIBRARY_PATH, then 
> CML  initialization completes without error and my 
> application proceeds on 
> its way.
>          The CML evidently attempts to manually load some 
> libraries at 
> init-time. Does this process involve the LD_LIBRARY_PATH 
> inherently? Is 
> there a workaround?
> 
>          Thanks,
> 
>                  Tony Stein
> 
> 
> 
> --------------------
> Tony Stein
> Software Engineer
> Information Security
> BBN Technologies
> astein@xxxxxxx
> --------------------
>