Re: Tune rpath by env. variable
Hi Pavel,
On Dec 13, 2014, at 5:58 PM, Pavel Raiskup prais...@redhat.com wrote:
On Friday 12 of December 2014 11:17:03 Gary V. Vaughan wrote:
I'll commit a follow on patch, to tweak it like this, later today.
Thanks for the patch! It is almost perfect. During testing I noted that
there is still one dollar sign not substituted with quadrigraph. Patch
0001 attached.
Also, I noted having LT_SYS_SEARCH_PATH=/lib64: specified in config.site
does not change libtool's content; it the LT_SYS_LIBRARY_PATH default
value stays empty. I would like to have it fixed before 2.4.5, if
possible, because I would like to enable something like the following in
our default /usr/share/config.site file:
if $arch_64bit; then
: ${LT_SYS_LIBRARY_PATH=/lib64:/usr/lib64:}
fi
Also, I'm not sure whether we should touch the lt_cv_sys_*. That should
not hurt too much but I would feel quite more safe if we use separate
variable and let the lt_cv_* for existing workarounds in the wild.
Something like the attachment 0002 would be nice to have pushed.
Thanks for the patches. I tweaked them to pass `make syntax-check`, applied
and pushed both.
That code seems like asking for test-case also?
The more the better!
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
___
https://lists.gnu.org/mailman/listinfo/libtool
Re: Tune rpath by env. variable
On Tuesday 20 of January 2015 07:40:20 Pavel Raiskup wrote:
Something like the attachment 0002 would be nice to have pushed.
This would be nice to have it in git also. The LT_SYS_SEARCH_PATH does
not survive automatic re-autoconf of configure script:
Argh :(, sorry. Fixing the example:
// libtool after LT_SYS_SEARCH_PATH=/lib64: ./configure
# Configured defaults for sys_lib_dlsearch_path munging.
: ${LT_SYS_LIBRARY_PATH=/lib64:}
// libtool after 'touch configure.ac ; make'
# Configured defaults for sys_lib_dlsearch_path munging.
: ${LT_SYS_LIBRARY_PATH=}
// ^^
___
https://lists.gnu.org/mailman/listinfo/libtool
Re: Tune rpath by env. variable
On Saturday 13 of December 2014 18:58:58 Pavel Raiskup wrote:
On Friday 12 of December 2014 11:17:03 Gary V. Vaughan wrote:
I'll commit a follow on patch, to tweak it like this, later today.
Thanks for the patch! It is almost perfect. During testing I noted that
there is still one dollar sign not substituted with quadrigraph. Patch
0001 attached.
Sorry for not pinging you because of this issue before the 2.4.5 release,
pinging now to get it fixed at least in 'master'. The LT_SYS_LIBRARY_PATH
variable is probably completely broken. Current problem:
$ LT_SYS_LIBRARY_PATH=/lib64: ./configure
[...]
checking dynamic linker characteristics... GNU/Linux ld.so
./configure: line 8532: @1: command not found
./configure: eval: line 8532: unexpected EOF while looking for matching `'
./configure: eval: line 8533: syntax error: unexpected end of file
checking how to hardcode library paths into programs... immediate
checking for shl_load... no
[...]
Also, I noted having LT_SYS_SEARCH_PATH=/lib64: specified in config.site
does not change libtool's content; it the LT_SYS_LIBRARY_PATH default
value stays empty. I would like to have it fixed before 2.4.5, if
possible, because I would like to enable something like the following in
our default /usr/share/config.site file:
if $arch_64bit; then
: ${LT_SYS_LIBRARY_PATH=/lib64:/usr/lib64:}
fi
Also, I'm not sure whether we should touch the lt_cv_sys_*. That should
not hurt too much but I would feel quite more safe if we use separate
variable and let the lt_cv_* for existing workarounds in the wild.
Something like the attachment 0002 would be nice to have pushed.
This would be nice to have it in git also. The LT_SYS_SEARCH_PATH does
not survive automatic re-autoconf of configure script:
// libtool after LT_SYS_SEARCH_PATH=/lib64:
# Configured defaults for sys_lib_dlsearch_path munging.
: ${LT_SYS_LIBRARY_PATH=/lib64:}
// libtool after 'touch configure.ac ; make'
# Configured defaults for sys_lib_dlsearch_path munging.
: ${LT_SYS_LIBRARY_PATH=/lib64:}
___
https://lists.gnu.org/mailman/listinfo/libtool
Re: Tune rpath by env. variable
On Friday 12 of December 2014 11:17:03 Gary V. Vaughan wrote:
I'll commit a follow on patch, to tweak it like this, later today.
Thanks for the patch! It is almost perfect. During testing I noted that
there is still one dollar sign not substituted with quadrigraph. Patch
0001 attached.
Also, I noted having LT_SYS_SEARCH_PATH=/lib64: specified in config.site
does not change libtool's content; it the LT_SYS_LIBRARY_PATH default
value stays empty. I would like to have it fixed before 2.4.5, if
possible, because I would like to enable something like the following in
our default /usr/share/config.site file:
if $arch_64bit; then
: ${LT_SYS_LIBRARY_PATH=/lib64:/usr/lib64:}
fi
Also, I'm not sure whether we should touch the lt_cv_sys_*. That should
not hurt too much but I would feel quite more safe if we use separate
variable and let the lt_cv_* for existing workarounds in the wild.
Something like the attachment 0002 would be nice to have pushed.
That code seems like asking for test-case also?
Thanks,
Pavel
From 562a2a74f7cbaf236aee46b88cf01e06217300cb Mon Sep 17 00:00:00 2001
From: Pavel Raiskup prais...@redhat.com
Date: Sat, 13 Dec 2014 10:59:37 +0100
Subject: [PATCH 1/2] libtool.m4: typofix, subst last '$' with quadrigraph
* m4/libtool.m4 (_LT_LIBTOOL_TAG_VARS): Encase the
configure/libtool shared function into parseable borders; for
testing purposes.
(func_munge_path_list): Typo s/$/@S|@/.
* tests/configure-funcs.at: New testcase.
* Makefile.am (TESTSUITE_AT): Mention new testcase.
---
Makefile.am | 1 +
m4/libtool.m4| 9 ---
tests/configure-funcs.at | 70
3 files changed, 76 insertions(+), 4 deletions(-)
create mode 100644 tests/configure-funcs.at
diff --git a/Makefile.am b/Makefile.am
index f1b7ead..ede28c7 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -651,6 +651,7 @@ testsuite = $(tests_dir)/testsuite
# that it can check for previous failures and skip if necessary.
TESTSUITE = tests/testsuite
TESTSUITE_AT = tests/testsuite.at \
+ tests/configure-funcs.at \
tests/libtoolize.at \
tests/libtool.at \
tests/demo.at \
diff --git a/m4/libtool.m4 b/m4/libtool.m4
index f879988..31431ee 100644
--- a/m4/libtool.m4
+++ b/m4/libtool.m4
@@ -748,13 +748,14 @@ _LT_LIBTOOL_TAG_VARS
_LT_EOF
cat '_LT_EOF' $cfgfile
-## -- ##
-## Shell functions shared with configure. ##
-## -- ##
+
+# ### BEGIN FUNCTIONS SHARED WITH CONFIGURE
_LT_PREPARE_MUNGE_PATH_LIST
_LT_PREPARE_CC_BASENAME
+# ### END FUNCTIONS SHARED WITH CONFIGURE
+
_LT_EOF
case $host_os in
@@ -2256,7 +2257,7 @@ func_munge_path_list ()
x)
;;
*:)
-eval @S|@1=\`$ECHO @S|@2 | $SED 's/:/ /g'` \$@S|@1\
+eval @S|@1=\`$ECHO @S|@2 | $SED 's/:/ /g'` \@S|@@S|@1\
;;
x:*)
eval @S|@1=\\@S|@@S|@1 `$ECHO @S|@2 | $SED 's/:/ /g'`\
diff --git a/tests/configure-funcs.at b/tests/configure-funcs.at
new file mode 100644
index 000..eab84a0
--- /dev/null
+++ b/tests/configure-funcs.at
@@ -0,0 +1,70 @@
+# configure-functions.at -- Linking and loading. -*- Autotest -*-
+#
+# Copyright (C) 2014 Free Software Foundation, Inc.
+#
+# This file is part of GNU Libtool.
+#
+# GNU Libtool is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# GNU Libtool is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GNU Libtool; see the file COPYING. If not, a copy
+# can be downloaded from http://www.gnu.org/licenses/gpl.html,
+# or obtained by writing to the Free Software Foundation, Inc.,
+# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+
+
+AT_BANNER([Functions shared with configure and libtool.])
+
+m4_define([_AT_FUNC_SETUP], [dnl
+AT_SETUP($1)dnl
+_lt_bin=$abs_top_builddir/libtool
+re_begincf='^# ### BEGIN FUNCTIONS SHARED WITH CONFIGURE'
+re_endcf='^# ### END FUNCTIONS SHARED WITH CONFIGURE'
+
+$ECHO '#!/bin/sh'$1
+$ECHO '#: ${SED=sed}'$1
+$ECHO '#: ${ECHO=echo}' $1
+
+sed 1,/$re_begincf/d;/$re_endcf/,\$d $_lt_bin $1
+])
+
+_AT_FUNC_SETUP([func_munge_path_list])
+
+cat \EOF func_munge_path_list
+for orig in /usr/lib /lib /usr/lib ; do
+ $ECHO '$orig':
+ for path in /p1: /p3:/p2: :/a1 :/a2:/a3 /p4::/a4 /p6:/p5::/a5:/a6; do
+old=$orig
+func_munge_path_list orig $path || exit 1
+$ECHO munge ($path) = $orig
+ done
+done
+EOF
+chmod +x func_munge_path_list
+
+AT_CHECK([ECHO=$ECHO SED=$SED ./func_munge_path_list], [0],
+['/usr/lib':
+munge
Re: Tune rpath by env. variable
On Thursday 11 of December 2014 23:29:56 Gary V. Vaughan wrote:
I applied your patch with some fairly heavy-handed changes:
1. Added a NEWS update.
2. Simplified the new documentation.
3. Changed the name of some internal API symbols.
4. Fixed dollar quoting with quadrigraphs, and then expand the shared
function directly into libtool.
Thanks a lot for all of this ^.
5. Remove the scripts for slicing and dicing that function out of one
file and into another the hard way.
The libtool's code is so sophisticated, thanks, thats perfect! I need
to give the code-reading another chance (yeah a minute or so) to review
everything properly; I'll do so but it looks fine to me now.
I still have some small concerns about the correctness.
Do we really want the configure time LT_SYS_LIBRARY_PATH adjusted
lt_lib_dlsearch_path_spec injected into the installed libtool script? That
makes me think that if LT_SYS_LIBRARY_PATH is set in /etc/profile or similar,
that the adjustment will happen twice.
Yes. Thats why I wanted let the libtool ignore environment var (to avoid
duplicities); and because for me, the ./configure time
LT_SYS_LIBRARY_PATH seems to be more important...
I think it would work better to leave lt_lib_dlsearch_path_spec in the
generated file as it was before (just the heuristic configure time values),
and add to the top of libtool:
: ${LT_SYS_LIBRARY_PATH=/configure/time:/path/list}
Then installed libtool will work whether the user wants to set it differently,
or not at all, or if LT_SYS_LIBRARY_PATH is set in the environment for both
configure and libtool, without double adjusting.
WDYT?
Thats definitely cleaner. Ack. I mean, only if we still can use
LT_SYS_LIBRARY_PATH to enhance ltdl.m4's runtime library path
during ./configure time. Now however, the path munging routine from
libtool.m4 should be easy to reuse in ltdl.m4. And also if:
LT_SYS_LIBRARY_PATH=/lib64:/usr/lib64: ./configure
.. is enough to to stop thinking about LT_SYS_LIBRARY_PATH during
development as it should survive things like 'touch configure.ac ; make'.
Pavel
___
https://lists.gnu.org/mailman/listinfo/libtool
Re: Tune rpath by env. variable
Hi Pavel,
On Dec 12, 2014, at 10:02 AM, Pavel Raiskup prais...@redhat.com wrote:
On Thursday 11 of December 2014 23:29:56 Gary V. Vaughan wrote:
I think it would work better to leave lt_lib_dlsearch_path_spec in the
generated file as it was before (just the heuristic configure time values),
and add to the top of libtool:
: ${LT_SYS_LIBRARY_PATH=/configure/time:/path/list}
Then installed libtool will work whether the user wants to set it
differently,
or not at all, or if LT_SYS_LIBRARY_PATH is set in the environment for both
configure and libtool, without double adjusting.
WDYT?
Thats definitely cleaner. Ack. I mean, only if we still can use
LT_SYS_LIBRARY_PATH to enhance ltdl.m4's runtime library path
during ./configure time. Now however, the path munging routine from
libtool.m4 should be easy to reuse in ltdl.m4. And also if:
LT_SYS_LIBRARY_PATH=/lib64:/usr/lib64: ./configure
.. is enough to to stop thinking about LT_SYS_LIBRARY_PATH during
development as it should survive things like 'touch configure.ac ; make'.
Right, and in that case we'd generate a libtool that contains:
: ${LT_SYS_LIBRARY_PATH=/lib64:/usr/lib64:}
sys_lib_dlsearch_path=/lib /usr/lib
[[...]]
func_munge_path_list ()
{
[[...]]
}
[[...]]
func_munge_path_list sys_lib_dlsearch_path $LT_SYS_LIBRARY_PATH
Which means by default libtool uses the configured additional paths, but
still has the flexibility for the caller to change them (cross-compiling
to Fedora?).
I'll commit a follow on patch, to tweak it like this, later today.
Thanks for the help and feedback!
Cheers,
--
Gary V. Vaughan (gary AT vaughan DOT pe)
___
https://lists.gnu.org/mailman/listinfo/libtool
Re: Tune rpath by env. variable
Hi Pavel,
On Dec 10, 2014, at 6:41 PM, Pavel Raiskup prais...@redhat.com wrote:
On Tuesday 09 of December 2014 19:38:53 Gary V. Vaughan wrote:
.. 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.
We will probably need to promote the macros required to support that to
libtool.m4 now that we care about setting sys_dlsearch_path_spec, without
requiring every package to use ltdl.m4.
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.
It's a lot of variables, but technically it seems sound to me.
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?
I think it would be easier to have both installed and in-tree libtool
respect LT_SYS_LIBRARY_PATH, otherwise we have to edit the installed script
to take out the substitution code.
Hi Gary, I tried to patch libtool according to previous discussion.
That requires good review, however. Patch attached.
Pavel
0001-libtool-allow-adjusting-run-time-library-path.patch
Many thanks for working on this.
I applied your patch with some fairly heavy-handed changes:
1. Added a NEWS update.
2. Simplified the new documentation.
3. Changed the name of some internal API symbols.
4. Fixed dollar quoting with quadrigraphs, and then expand the shared
function directly into libtool.
5. Remove the scripts for slicing and dicing that function out of one
file and into another the hard way.
I still have some small concerns about the correctness.
Do we really want the configure time LT_SYS_LIBRARY_PATH adjusted
lt_lib_dlsearch_path_spec injected into the installed libtool script? That
makes me think that if LT_SYS_LIBRARY_PATH is set in /etc/profile or similar,
that the adjustment will happen twice.
I think it would work better to leave lt_lib_dlsearch_path_spec in the
generated file as it was before (just the heuristic configure time values),
and add to the top of libtool:
: ${LT_SYS_LIBRARY_PATH=/configure/time:/path/list}
Then installed libtool will work whether the user wants to set it differently,
or not at all, or if LT_SYS_LIBRARY_PATH is set in the environment for both
configure and libtool, without double adjusting.
WDYT?
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
___
https://lists.gnu.org/mailman/listinfo/libtool
Re: Tune rpath by env. variable
On Tuesday 09 of December 2014 19:38:53 Gary V. Vaughan wrote: .. 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. We will probably need to promote the macros required to support that to libtool.m4 now that we care about setting sys_dlsearch_path_spec, without requiring every package to use ltdl.m4. 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. It's a lot of variables, but technically it seems sound to me. 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? I think it would be easier to have both installed and in-tree libtool respect LT_SYS_LIBRARY_PATH, otherwise we have to edit the installed script to take out the substitution code. Hi Gary, I tried to patch libtool according to previous discussion. That requires good review, however. Patch attached. Pavel From fdc38af01a9079f712787db451ca6003101d53f1 Mon Sep 17 00:00:00 2001 From: Pavel Raiskup prais...@redhat.com Date: Sat, 6 Dec 2014 16:35:41 +0100 Subject: [PATCH] libtool: allow adjusting run-time library path Some GNU/Linux distributions install libraries into /lib64 (or /usr/lib64) on 64-bit machines, while /lib (/usr/lib respectively) stays for multilib variant. Other distributions keep /usr/lib for 64-bit variant and reserve other directory for multilib. Distributions also have ldconfig configured properly to search corresponding library PATH. For libtool, it is quite difficult to detect which approach the particular GNU/Linux box uses, however. Glibc's ldconfig does not provide complete PATH either. So, by using LT_SYS_LIBRARY_PATH we are able to enhance the dynamic library search path now, either during ./configure time, or at run-time. References: http://thread.gmane.org/gmane.comp.gnu.libtool.general/8339/focus=8345 * m4/libtool.m4 (_LT_PATH_ENHANCE): New function to parse the new path format. Defines func_path_enhance () shell function. (_LT_SYS_DYNAMIC_LINKER): Requires _LT_PATH_ENHANCE. AC_ARG_VAR the LT_SYS_LIBRARY_PATH (to survive automatic autoreconf). Avoid hardcoding list of CPUs. Call the new func_path_enhance on sys_lib_dlsearch_path_spec - this propagates results to ltdl.m4. * build-aux/ltmain.in: Expand the func_path_enhance function. * Makefile.am (SCRIPT_ENV): Add $(AWK). (m4_expand, m4_extract): New variables. (EXTRA_DIST): Mention the two new vars ^. (bootstrap_edit): Substitute also @libtool_m4@. ($ltmain_sh): Pipe through $(m4_expand) also. * build-aux/m4-expand: New helper to extract code from m4 file for other use. * build-aux/m4-extract: Likewise. * doc/libtool.texi: Document new LT_SYS_LIBRARY_PATH. * doc/notes.texi: Likewise. --- Makefile.am | 13 build-aux/ltmain.in | 7 +++ build-aux/m4-expand | 18 build-aux/m4-extract | 17 +++ doc/libtool.texi | 20 ++ doc/notes.texi | 11 +- m4/libtool.m4| 58 +++- 7 files changed, 125 insertions(+), 19 deletions(-) create mode 100755 build-aux/m4-expand create mode 100755 build-aux/m4-extract diff --git a/Makefile.am b/Makefile.am index f1b7ead..f7a2078 100644 --- a/Makefile.am +++ b/Makefile.am @@ -54,7 +54,7 @@ rebuild = rebuild=:; revision=`$(lt__cd) $(srcdir) $(git_version_gen) | $(SED # Bootstrap. # # -- # -SCRIPT_ENV = GREP='$(GREP)' SED='$(SED)' +SCRIPT_ENV = GREP='$(GREP)' SED='$(SED)' AWK='$(AWK)' build_scripts = $(srcdir)/$(aux_dir)/announce-gen \ $(srcdir)/$(aux_dir)/do-release-commit-and-tag \ @@ -86,16 +86,20 @@ ltmain_in = $(srcdir)/$(aux_dir)/ltmain.in libtool_m4 = $(srcdir)/$(macro_dir)/libtool.m4 ltversion_in = $(srcdir)/$(macro_dir)/ltversion.in ltversion_m4 = $(srcdir)/$(macro_dir)/ltversion.m4 +m4_expand = $(srcdir)/$(aux_dir)/m4-expand +m4_extract = $(srcdir)/$(aux_dir)/m4-extract options_parser = $(srcdir)/$(aux_dir)/options-parser EXTRA_DIST += $(extract_trace) $(funclib_sh) $(inline_source) \ $(libtoolize_in) $(ltmain_in) $(ltmain_sh) \ - $(ltversion_in) $(ltversion_m4) $(options_parser) + $(ltversion_in) $(ltversion_m4) $(options_parser) \ + $(m4_extract) $(m4_expand) ## These are the replacements that need to be made at bootstrap time, ## because they must be static in distributed files, and not accidentally ## changed by configure running on the build machine. bootstrap_edit = $(SED) \ + -e 's|@libtool_m4\@|$(libtool_m4)|g' \ -e 's|@MACRO_VERSION\@|$(VERSION)|g' \ -e s|@MACRO_REVISION\@|$$revision|g \ -e s|@MACRO_SERIAL\@|$$serial|g \ @@ -162,8 +166,9 @@ $(ltmain_sh):
Tune rpath by env. variable (was: Use ldconfig to generate sys_lib_dlsearch_path_spec)
On Monday 08 of December 2014 15:55:22 Gary V. Vaughan wrote:
[..]
LT_SYS_LIBRARY_PATH
[..]
That LT_SYS_LIBRARY_PATH concept sounds good, thanks!
* 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?
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}?
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?
Cowardly, I know.., thats not what I initially said, sorry. But more I
read the history of this issue, more unsure I'm. I'm not 100% against
that so don't take me too seriously:
It has been proven it works for Fedora and it does not break Debian [1]
(though that patch does not follow debian's policy). On the other hand,
taking into account there can be /usr/lib32-like GNU/Linux distributions..
or just user setups..
If there are reasons to not apply this unconditionally at least for
GNU/Linux (and there surely are), I'm not sure whether we shouldn't
rather avoid such 'linux*' subset(64-bit arches) only conditions
(because reasons for not to do it must be the same). And that can result
in more tricky debugging scenarios.
[1] https://wiki.debian.org/RpathIssue
Pavel
___
https://lists.gnu.org/mailman/listinfo/libtool
Re: Tune rpath by env. variable (was: Use ldconfig to generate sys_lib_dlsearch_path_spec)
[remembered to remove Orion from the Cc: list this time as requested]
Hi Pavel,
On 9 Dec 2014, at 08:14, Pavel Raiskup prais...@redhat.com wrote:
On Monday 08 of December 2014 15:55:22 Gary V. Vaughan wrote:
[..]
LT_SYS_LIBRARY_PATH
[..]
That LT_SYS_LIBRARY_PATH concept sounds good, thanks!
* 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?
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.
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?
Cowardly, I know.., thats not what I initially said, sorry. But more I
read the history of this issue, more unsure I'm. I'm not 100% against
that so don't take me too seriously:
It has been proven it works for Fedora and it does not break Debian [1]
(though that patch does not follow debian's policy). On the other hand,
taking into account there can be /usr/lib32-like GNU/Linux distributions..
or just user setups..
If there are reasons to not apply this unconditionally at least for
GNU/Linux (and there surely are), I'm not sure whether we shouldn't
rather avoid such 'linux*' subset(64-bit arches) only conditions
(because reasons for not to do it must be the same). And that can result
in more tricky debugging scenarios.
[1] https://wiki.debian.org/RpathIssue
Pavel
Okay, I agree with your arguments, and will revert the hardcoded settings
before applying your patch.
Cheers,
Gary V. Vaughan (gary AT gnu DOT org)
___
https://lists.gnu.org/mailman/listinfo/libtool
Re: Tune rpath by env. variable
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
Re: Tune rpath by env. variable
On Dec 9, 2014, at 1:53 PM, Pavel Raiskup prais...@redhat.com wrote:
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..
Hmmm... I think you're right.
.. 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.
We will probably need to promote the macros required to support that to
libtool.m4 now that we care about setting sys_dlsearch_path_spec, without
requiring every package to use ltdl.m4.
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.
It's a lot of variables, but technically it seems sound to me.
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?
I think it would be easier to have both installed and in-tree libtool
respect LT_SYS_LIBRARY_PATH, otherwise we have to edit the installed script
to take out the substitution code.
Cheers,
--
Gary V. Vaughan (gary AT gnu DOT org)
___
https://lists.gnu.org/mailman/listinfo/libtool
