[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Use ldconfig to generate sys_lib_dlsearch_path_spec

From: Gary V. Vaughan
Subject: Re: [PATCH] Use ldconfig to generate sys_lib_dlsearch_path_spec
Date: Mon, 8 Dec 2014 15:55:22 +0000

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
> Iteration #1 attached, more complete hopefully,

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 
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:


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 
  LT_SYS_LIBRARY_PATH="/lib64:/usr/lib64:/lib:/usr/lib"         # override 

>>  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... 
seems not that useful for it to be only at configure time, since we also want 
installed libtool to honor changes in the environment.  Or do we bake the 
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 
flexible, at the expense of being centralised in


>> Benefits would be:
>> * No need to touch ac_cv_* at least for our (Fedora) case.
>> * Can be easily set in ${prefix}/share/
>> * 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 ^.


Gary V. Vaughan (gary AT vaughan DOT pe)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]