| The runtime loader is complaining that it cannot find a library; the loader
only looks in specific places for libraries that are needed by the application.
(see the loader(5) manpage for information on the 'standard locations) That
is why putting them in /usr/lib 'works'. The loader has always worked
this way, nothing new about that in V4.0.
It's hard to guess what might be wrong based on the limited information
provided, but here's a guess: Does this application link -non_shared?
The 'setlocale()' call is implemented via some runtime loader magic.
Prior to V4.0, you could not use locales with -non_shared programs, as the
runtime loader magic did not work in -non_shared programs.
That would explain why setting the locale changes the behavior. However,
'libaiarclib.so' does not look like the name of a locale to me, so something
else is probably going on here too.
An example or at least the makefile that builds the application would
be necessary to figure out much more.
|
| A couple possibilities.
1. As Craig said, if /aruba1/esri72.axp/arcexc72/bin/build is
linked -non_shared, then in 4.0 the new non-shared locale
support is somehow trying to pick up the libaiarclib.so
which its not finding in any of the standard library search
directories. See the loader(5) man page.
Since I've never registered libaiarclib.so as one of the locale
libraries this is probably not what's happening.
2. Shared or non-shared, maybe the locale library is pushing the
program over its datasize limit. Or if it's using a lot of
shared libraries, it could be exceeding its mapentries limit.
|