Re: [PATCH] Use ldconfig to generate sys_lib_dlsearch_path_spec

[Gary V. Vaughan]

Hi Pavel,

Many thanks for the patch!

> On Dec 8, 2014, at 2:16 PM, Pavel Raiskup <address@hidden> wrote:
> 
> On Saturday 06 of December 2014 14:36:23 Pavel Raiskup wrote:
>> Iteration #0.  Patch (for discussion, not push) implementing configure
>> time PREPEND_LIB_DLSEARCH_PATH variable.  Possible enhancements for future
>> could be {APPEND_,}LIB_DLSEARCH_PATH and
>> {,APPEND_,PREPEND_}LIB_SEARCH_PATH.
> 
> Iteration #1 attached, more complete hopefully,
> s/PREPEND_LIB_DLSEARCH_PATH/LIB_DLSEARCH_PATH_PREPEND/.

I'll ignore the first then, which came and went while I was offline over the
weekend :-)

>> Questions:
>> * Is the name good-enough?

It seems rather long to me.  Also, to clarify we are talking entirely about
what libtool will inject into the runtime load path only here 
(lt_cv_sys_dlsearch_path
as opposed to lt_cv_sys_search path), right?

Since libtool is trying hard to expose a uniform interface that developers might
already feel comfortable with, I would prefer to name the environment variable:

  LT_SYS_LIBRARY_PATH

and rather than prepend it to libtool's best guess list, let the user/sysadmin 
specify a
dangling colon where $lt_cv_sys_dlsearch_path should go; i.e.

  LT_SYS_LIBRARY_PATH="/lib64:/usr/lib64:"  # prepend named directories
  LT_SYS_LIBRARY_PATH=":/lib32:/usr/lib32"  # append named directories
  LT_SYS_LIBRARY_PATH="/usr/lib/sparcv9::/opt/lib/sparcv9"      # prepend and 
append!
  LT_SYS_LIBRARY_PATH="/lib64:/usr/lib64:/lib:/usr/lib"         # override 
entirely

>>  Any namespace should be used?

There's no precedent for Libtool's interface with the environment, but LT_ 
seems like
a safe bet, and SYS_ might prevent confusion with the way LD_LIBRARY_PATH works.

>> * should I use AC_ARG_VAR rather?

I'm not entirely clear yet exactly when the extra directories are important... 
It
seems not that useful for it to be only at configure time, since we also want 
our
installed libtool to honor changes in the environment.  Or do we bake the 
configure
time setting into the installed and client project generated libtool always?

If at configure time only, AC_ARG_VAR is sensible, but at libtool time seems 
more
flexible, at the expense of being centralised in config.site.

WDYT?

>> Benefits would be:
>> * No need to touch ac_cv_* at least for our (Fedora) case.
>> * Can be easily set in ${prefix}/share/config.site.
>> * Does not break libtool's dlsearch path guesses.
>> * Avoiding hard-wiring list of $host_cpu.

If $host_cpu heuristics are an improvement, then I don't think it hurts to leave
them, so that LT_SYS_LIBRARY_PATH is not always necessary.  Is it the case that
adding /lib64:/usr/lib64 is a pessimisation in some case?

>> * Should be fully backward compatible.
> 
> Still valid ^.

Ack.

Cheers,
-- 
Gary V. Vaughan (gary AT vaughan DOT pe)