Re: a (different) library question

[steve%prd.co.uk@localhost (Steve Blinkhorn)]

Thanks for the responses to date.  On a couple of points raised,
the software suite on the wo machines is identical in the sense that
it was copied from one machine, and then tweaked just in startup files
that identify the machine, its DNS and IP identity etc.  So I think
it is most unlikely that given that there is no difference in file
sizes or timestamps on the files that there are differences there.
None of the startup files involves setting a library path.  The
machine in question is intended as a failover machine, and rarely does
much work, but was called on for a short period last Friday.

ktrace is, I suspect, a non-starter.   Because it is a scripting
language with LISP-like features, it would be a sledgehammer to crack
what is probably quite a small nut, and probably take a long time.
I know exactly where and when at the script level the failure occurs:
it is replicable ad nauseam, but the rest of the code works perfectly,
and continues to work despite the failure (which is to do with
formatting data for display).

The rpath suggestion seems the most likely way forward.   Is there a
way of getting the library search list/order from a running program,
or from the executable file?   Tcl certainly does allow arbitrary
dynamic libraries to be loaded at run time (it is even possible for
Tcl code to write new code itself dynamically involving the loading of
an arbitrary library, though nothing so complex is going on here).
I'm asking the same question of the Tcl community.   My instinct is
that there is some missing or misplaced file or directory in the
layout of the machine in question.


--
Steve Blinkhorn <steve%prd.co.uk@localhost>
You wrote:
> 
> On Mon, 24 Sep 2018 at 19:32, Steve Blinkhorn <steve%prd.co.uk@localhost> wrote:
> > I have two essentially identical machines that are application servers
> > for our customers.  The custom software that provides the service is
> > 32-bit, and has been running for years on i386 machines, and runs
> > perfectly on one of the new servers, and nearly perfectly on the
> > other.   But 'nearly' is not good enough.   An error is thrown at one
> > particular point, of the style "Sharedobject libxxxx.so not found".
> > Said shared object is in /usr/local/lib on both machines, and only in
> > /usr/local/lib.   Neither machine has any ld.so.conf file, nor is
> > there a library search path in the environment.   What is really odd
> 
> Is this dynamic library loaded by ld.so as a dependency of your
> executable, as shown by ldd(1)? Or is it required transitively by
> another library, in which case the search would take into account
> their respective rpath which might be different between machines.
> 
> If the error is reported when the application is already running this
> might indicate the shared object is loaded using dlopen()? I'm not
> familiar with Tcl, but there could be a way to load shared objects
> from scripts using arbitrary search paths.
> 
> HTH
> 
> Joachim
>