On Tuesday 09 of December 2014 11:53:22 Gary V. Vaughan wrote:
> > That makes sense. Ideally, we could make the variable ./configure time
> > sensitive and also sensitive to environment. Something like
> > : ${LT_SYS_LIBRARY_PATH="/configure/time/detected/LT_SYS_LIBRARY_PATH"}?
>
> Great. The only wrinkle I can see here is that we need the function for
> injecting lt_cv_sys_dlsearch_path into the dangling colon in the runtime
> LT_SYS_LIBRARY_PATH shared between libtool.m4 and ltmain.in.
> I haven't double checked, but I'm certain we have functions that are
> shared like this without duplicated code already we can copy from.
Ouch, thats quite complicated.
If you think about new LT_SYS_LIBRARY_PATH like its just something which
enhances 'sys_dlsearch_path_spec', then that code-share should not be
necessary? There would be two coexisting variables - and only libtool
binary (ltmain.sh) should be able to deal with that. LT_SYS_LIBRARY_PATH
could be just overwritten at libtool time if defined in environment. But
all that dependencies are quite confusing so I can be wrong..
.. however, maybe you think that quite problematic the share with ltdl.m4
(via sys_lib_dlsearch_path). That is ?clearly? configure-time only
variable which generates variable LT_DLSEARCH_PATH in c-header file.
In this case, using LT_SYS_LIBRARY_PATH at runtime would differentiate
LT_DLSEARCH_PATH with libtool's 'sys_dlsearch_path_spec' ... and could
cause confusion later.
Hmm, due to its requirments, it seems like LT_SYS_LIBRARY_PATH should be
AC_ARG_VAR-ed. The system-wide libtool should be pre-configured correctly
according to system's needs anyway. WDYT?
Pavel
_______________________________________________
https://lists.gnu.org/mailman/listinfo/libtool
