Re: Shared libraries on Solaris (ITS#376)

[kurt@boolean.net]

At 06:10 PM 12/4/99 GMT, bbense@networking.stanford.edu wrote:
>On Sat, 4 Dec 1999, Kurt Zeilenga wrote:
>
>> There is no portable way to ensure that a executable built in
>> one environment will run in another environment.  We require
>> the installer to tune their environment such that the built
>> executable will run in most user environments.
>> 
>> That is, if the installer has specified to use and locate
>> shared libraries not in the default search path, then the
>> installer is responsible to provide options and flags (such
>> as -R) to configure to ensure built executables can locate
>> detected libraries at run time.
>> 
>
>- But, it is in the default search path. If the configure script
>adds the -L options it should be smart enough to add the 
>-R options.

Our configure script never adds -L options.  We do not assume
the $CC understands -L or -R or whatever.  If it is in the
default search path, then the user must have something in
her environment to use an alternative search path (or alternative
dynamic linker).

>I didn't give it any special compile options, I
>just typed configure.

Something in your environment that specified to use a
non-default search path.  It could be any number of things
to which the configure script is aware of.

>If the configure script is going to look in /usr/local without
>my telling it, it should be prepared to deal with finding a
>shared library there. 

If /usr/local is not in your systems default search path, then
you must have told it to look their or the user is using a
complete differnet dynamic linker.  The configure script
does not modify search paths, it defers this responsibility
to the user.

>- I fully see your position if I had specified something 
>like -L/usr/special/place, it's up to me to add the -R option. 

Exactly.  If the user adds a -L without adding a -R, that's
his problem.  We can not and should not second guess the user.

Of course, the compiler/linker selected by the user may have
other means for muckying with search paths.  The configure
script is clueless on how to resolve this issue.  It just
does what the user tells it to do.

>-If the configure script is not going to deal with it, I would
>suggest that you add something to the build documentation to
>warn people about the issue. 

Such a warning would best be placed in autoconf documentation
as it is not specific to OpenLDAP.
	
WARNING: any program built within a particular environment
  may not be portable to other environments.


----
Kurt D. Zeilenga		<kurt@boolean.net>
Net Boolean Incorporated	<http://www.boolean.net/>