Re: Why does ltmain.sh::temp_rpath not need the same system lib considerations?
On Thu, 16 Feb 2017, Nish Aravamudan wrote: I do not believe so, the tests (heimdal self-tests) are run via a Makefile target which calls the generated wrapper script(s). Normally if you call the generated wrapper scripts, things should be ok, as long as the linkage was correct in the first place. I really appreciate the response! From what I can tell, though, the temp_rpath variable is not actually used to compile/link anything, it's only used for the wrapper script generator. And I don't understand how it would be correct for an explicit LD_LIBRARY_PATH specification (as done by the wrapper generator) to have the system library path anywhere before the end of the list. Otherwise, if any of the required library dependencies are installed, the somewhat arbitrary set before the system library path in LD_LIBRARY_PATH will use the built libraries and the somewhat arbitrary set after the system library path in LD_LIBRARY_PATH will use the system libraries without any indication of a problem -- and it becomes rather murky what is actually being tested. I don't think that it is normal or ok to have the system library path in the list at all. Perhaps libtool is not determining that the path is a system library path. Check the output of './libtool --config'. Particularly, sys_lib_dlsearch_path_spec. Maybe it is wrong. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Why does ltmain.sh::temp_rpath not need the same system lib considerations?
On 16.02.2017 [17:39:59 -0600], Bob Friesenhahn wrote: > On Thu, 16 Feb 2017, Nish Aravamudan wrote: > > > I am trying to get to the bottom of an odd build failure on Ubuntu 17.04 > > with heimdal. I believe the underlying issue is a bug in libtool, but > > I'm not confident in my analysis (some of it is also at > > https://github.com/heimdal/heimdal/issues/241), but here's what I have, > > I would appreciate any feedback! > > > > Using the system sqlite3 (/usr/lib/x86_64-linux-gnu/) via configure, we > > end up inserting the above path into LD_LIBRARY_PATH for build-time > > generated wrapper scripts and since we also happen to have heimdal > > libraries install at the system-level, the system heimdal libraries are > > used by the tests instead of the build-local ones. This is bad for two > > reasons: a) it fails in this case because of an ABI mismatch and b) we > > are trying to test the built libraries, not the system installed ones > > when the library in question is built by this package. > > Do your test cases use > > ./libtool --mode=execute ./testprogram > > or equivalent to assure that ./testprogram is executed with correct library > paths? I do not believe so, the tests (heimdal self-tests) are run via a Makefile target which calls the generated wrapper script(s). > > It seems like there is rarely, if ever, a case to put a system library > > path before a non-system library path in the wrapper script, and in > > particular, it seems like ltmain.sh actually detects adding the system > > path to compile_rpath and finalize_rpath. Is it correct to do the same > > elision in temp_rpath? e.g. > > Without studying the details, it is worth noting that other software > delivering libraries does manage to successfully test the uninstalled > libraries even if installed libraries are present. For operating systems > where this is deemed not possible (or which hard code paths to the libraries > used), libtool builds with hard-coded run-paths and then re-links at install > time. This is Linux, if it matters (Ubuntu 17.04) -- I will look at these libtool options. > Problems could still occur if a library used has a hard-coded run path baked > into it so that the undesired directory is still used. Right, we'd want the installed library(ies) to use the system for satisfying dependencies. > Problems could also accur if libraries are linked in the wrong order (e.g. > building/linking in the wrong order in a recursive build) or with wrong > paths such that a system library was used. Right. > I am definitely aware of issues under Microsoft Windows, which does not seem > to offer sufficient control of where files come from. I really appreciate the response! From what I can tell, though, the temp_rpath variable is not actually used to compile/link anything, it's only used for the wrapper script generator. And I don't understand how it would be correct for an explicit LD_LIBRARY_PATH specification (as done by the wrapper generator) to have the system library path anywhere before the end of the list. Otherwise, if any of the required library dependencies are installed, the somewhat arbitrary set before the system library path in LD_LIBRARY_PATH will use the built libraries and the somewhat arbitrary set after the system library path in LD_LIBRARY_PATH will use the system libraries without any indication of a problem -- and it becomes rather murky what is actually being tested. Thanks, Nish -- Nishanth Aravamudan Ubuntu Server Canonical Ltd ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: Why does ltmain.sh::temp_rpath not need the same system lib considerations?
On Thu, 16 Feb 2017, Nish Aravamudan wrote: I am trying to get to the bottom of an odd build failure on Ubuntu 17.04 with heimdal. I believe the underlying issue is a bug in libtool, but I'm not confident in my analysis (some of it is also at https://github.com/heimdal/heimdal/issues/241), but here's what I have, I would appreciate any feedback! Using the system sqlite3 (/usr/lib/x86_64-linux-gnu/) via configure, we end up inserting the above path into LD_LIBRARY_PATH for build-time generated wrapper scripts and since we also happen to have heimdal libraries install at the system-level, the system heimdal libraries are used by the tests instead of the build-local ones. This is bad for two reasons: a) it fails in this case because of an ABI mismatch and b) we are trying to test the built libraries, not the system installed ones when the library in question is built by this package. Do your test cases use ./libtool --mode=execute ./testprogram or equivalent to assure that ./testprogram is executed with correct library paths? It seems like there is rarely, if ever, a case to put a system library path before a non-system library path in the wrapper script, and in particular, it seems like ltmain.sh actually detects adding the system path to compile_rpath and finalize_rpath. Is it correct to do the same elision in temp_rpath? e.g. Without studying the details, it is worth noting that other software delivering libraries does manage to successfully test the uninstalled libraries even if installed libraries are present. For operating systems where this is deemed not possible (or which hard code paths to the libraries used), libtool builds with hard-coded run-paths and then re-links at install time. Problems could still occur if a library used has a hard-coded run path baked into it so that the undesired directory is still used. Problems could also accur if libraries are linked in the wrong order (e.g. building/linking in the wrong order in a recursive build) or with wrong paths such that a system library was used. I am definitely aware of issues under Microsoft Windows, which does not seem to offer sufficient control of where files come from. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ https://lists.gnu.org/mailman/listinfo/libtool
Why does ltmain.sh::temp_rpath not need the same system lib considerations?
I am trying to get to the bottom of an odd build failure on Ubuntu 17.04 with heimdal. I believe the underlying issue is a bug in libtool, but I'm not confident in my analysis (some of it is also at https://github.com/heimdal/heimdal/issues/241), but here's what I have, I would appreciate any feedback! Using the system sqlite3 (/usr/lib/x86_64-linux-gnu/) via configure, we end up inserting the above path into LD_LIBRARY_PATH for build-time generated wrapper scripts and since we also happen to have heimdal libraries install at the system-level, the system heimdal libraries are used by the tests instead of the build-local ones. This is bad for two reasons: a) it fails in this case because of an ABI mismatch and b) we are trying to test the built libraries, not the system installed ones when the library in question is built by this package. It seems like there is rarely, if ever, a case to put a system library path before a non-system library path in the wrapper script, and in particular, it seems like ltmain.sh actually detects adding the system path to compile_rpath and finalize_rpath. Is it correct to do the same elision in temp_rpath? e.g. --- a/ltmain.sh +++ b/ltmain.sh @@ -8092,9 +8092,16 @@ func_mode_link () # We need to hardcode the library path if test -n "$shlibpath_var" && test -z "$avoidtemprpath"; then # Make sure the rpath contains only unique directories. - case $temp_rpath: in - *"$absdir:"*) ;; - *) func_append temp_rpath "$absdir:" ;; + # Skip directories that are in the system default run-time + # search path. + case " $sys_lib_dlsearch_path " in + *" $absdir "*) ;; + *) + case $temp_rpath: in + *"$absdir:"*) ;; + *) func_append temp_rpath "$absdir:" ;; + esac + ;; esac fi Doing the above does result in passing testcases, but I'm not sure why this isn't seen in other environments or if the above change is a bad idea. Thanks! -Nish -- Nishanth Aravamudan Ubuntu Server Canonical Ltd ___ https://lists.gnu.org/mailman/listinfo/libtool
