ARY_PATH searched ahead of the compiled-in
+# rpath, if no DT_RUNPATH is present in the executable. The conditions
+# under which DT_RUNPATH are added seem unpredictable, so be safe.
+
+define with_temp_install_extra
+LD_LIBRARY_PATH_RPATH=1
+endef
# Rule for building a shared library from a sing
Andrew Gierth writes:
> Is there some reason why ld_library_path_var is defined using a bunch of
> $(if) constructs rather than putting the value (if not LD_LIBRARY_PATH)
> in the individual port makefiles?
I might be wrong, but I think that code is Peter's. I agree that
having the per-port make
;> will be the final install dir, which may of course contain old
>> libraries).
>> LD_LIBRARY_PATH_RPATH=1 fixes this (by giving LD_LIBRARY_PATH priority
>> over the DT_RPATH tag in the object).
>> Is this also an issue on any other platforms?
Tom> Hm. Can't
which will be the final install dir, which may of course
>> contain old libraries).
>> LD_LIBRARY_PATH_RPATH=1 fixes this (by giving LD_LIBRARY_PATH
>> priority over the DT_RPATH tag in the object).
>> Is this also an issue on any other platforms?
Tom> Hm. Can't
contain old
> libraries).
> LD_LIBRARY_PATH_RPATH=1 fixes this (by giving LD_LIBRARY_PATH priority
> over the DT_RPATH tag in the object).
> Is this also an issue on any other platforms?
Hm. Can't reproduce that on current NetBSD or macOS; don't have
OpenBSD booted up to try r
At least on my FreeBSD 11 box, the current definition of
$(with_temp_install) is not sufficient to ensure that the various .so
files are loaded from tmp_install and not from the compiled rpath (which
will be the final install dir, which may of course contain old
libraries).
LD_LIBRARY_PATH_RPATH
