[GE users] LD_LIBRARY_PATH (was: One last concern)

Andy Schwierskott andy.schwierskott at sun.com
Tue Nov 23 08:49:06 GMT 2004


> On Fri, 2004-11-19 at 11:08, Rayson Ho wrote:
>> I think it should be easy... may be an hour of programming would do it.
>> The library location should always be:
>> $SGE_ROOT/lib/<arch>/<lib name>
>> Is there a case that the library directory can be moved to a different
>> location??
> I have an SGE rpm I made that actually puts the SGE library files in
> /usr/lib.  However, I got tired of patching SGE to make everything work,
> so I ended up making $SGE_ROOT/lib/<arch> a symlink to /usr/lib.
> But what libraries are we talking about?  If its the openssl libraries,
> I don't agree that those should even be installed by SGE in the first
> place.  (that creates an extra set of openssl libraries that won't be
> updated when there are security issues, which is a very very bad thing)

wise words - a fully agree. But reality will look different. The shout from
users who will have incompatible libraries on their systems and who will
*heavily* demand openssl libs shipped wiht Grid Engine will be significant.

In my opinion the openssl project is a project which doesn't well address
the needs (to spell it out politlely) which should be provided by a producer
of a central library used today by many different apps. Just think about the
difference between openssl 0.9.6 and 0.9.7 (e.g. certificate format). And
even in the most recent patch to 0.9.7 they made some small chances which
made our install Grid fail - with the same dot-dot release! In such a
situation it's more or less a dream to expect that a third party software
(like SGE) should expect to work with the preinstalled library found on the
systme by default.

Unless the openssl project will drastically change their project rules and
address the needs of long term compatibility chances are low in my opinion
that your wish becomes possible.

Achieving API, output/input format and file format compatibilty is certainly
one of the bigger challenges in software engineering (I'm not saying we
fully respect this rule in our own project;-) - adressing these needs means
significantly increase your development and QA efforts and results in
slowing down your (feature) progress - I think these are not all easy to
accept challenges for many open source developers.


To unsubscribe, e-mail: users-unsubscribe at gridengine.sunsource.net
For additional commands, e-mail: users-help at gridengine.sunsource.net

More information about the gridengine-users mailing list