James Hawtin wrote:
> If this is no a linux box, why not add /usr/local/ssl/lib to your
> /etc/ld.so.conf and run ldconfig if you use /usr/local/lib add that
> insted.
It is not a Linux box, but something similar exists, so I could use that.
But which procedure should I follow to determine if some other binary
would be screwed with that? The default library search path in run-time
is /usr/lib, just /usr/lib and nothing except /usr/lib. If I add
/usr/local/lib in front of that, I would change the run-time environment
which is assumed by every executable and shared object on the system.
How do I check if one of them would pick the wrong library if this change
is made? How often do I need to perform this check? Why would I want to do
it, considering the fact that the platform offers decent build
instructions and features?
> If that all fails try setting LD_RUN_PATH=/usr/local/ssl/lib before
> compile or LD_LIBRARY_PATH=/usr/local/ssl/lib after compile
On the platform in question LD_RUN_PATH is ignored if there is -R flag
specified when invoking ld utility.
> Generally it is GOOD practace not to set -R as this ends up with compiled
> in library paths, which cause problems later when you what your libraries
> in a different place, HPUX is a real sucker for this.
Platform documentation for the platform in questions says that it's always
a good practice to use hard-coded run-paths (which can be achieved by -R
flag, among other ways). In fact, it claims that you'd run into problems
sooner or latter if you don't do that. And it says that the platform
doesn't guarantee anything about the correct execution of your binaries if
you don't follow the recommended practice.
And the platform in question has a way to move libraries and executables
which have hardcoded run paths.
In general, build procedure differs among platforms. What's correct for
one platform does not have to be correct for another. Try to have that in
mind and don't recommend build procedure which is fine on one platform as
a solution for another. Each platform should have a decent documentation
about building binaries and libraries. So RTFM. If the manual (or feature
set) is not satisfactory, consider using another platform.
> LD_LIBRARY_PATH works on all SVR4 unixs, and the only times when you
> cannot use it is when the executable is setuid, (to stop library spoofing)
The platform in question is SVR4 Unix, but LD_LIBRARY_PATH usage is
strongly deprecated. Very, extremely and completely deprecated.
And there is a way to make LD_LIBRARY_PATH working with setuid executables
without security holes. In fact, I'm using that feature right now, just
because two Oracle utilities were not correctly built and I don't have the
source (or object files), so I can't rebuild. But when I have the source,
I don't want to rely on OS features to be able to run improperly built
binaries. I want to build them correctly, for a start.
> Not finding a dynamically linked library is not "instability", its
> incorrect OS configuration.
That might be true for some platform, although none comes to my mind.
It is certainly not true for all platforms. I always thought that it's
perfectly possible to build binary incorrectly (not according to platform
documentation, to be more precise) and that the OS configuration wouldn't
be guilty of anything in that case. Like with those two Oracle pieces of
crap.
> If you don't like any of those options sim link the .so into /usr/lib
> which will be in your global run path
Even if the platform documentation says you shouldn't?
--
.-. .-. Sarcasm is just one more service we offer.
(_ \ / _)
| [EMAIL PROTECTED]
|
