Date: Wed, 19 Oct 2016 02:10:18 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-ports-bugs@FreeBSD.org Subject: [Bug 213547] Mk/Scripts/qa.sh - hard-coded LD_LIBRARY_PATH causes false positives Message-ID: <bug-213547-13-F7lhoodkmd@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-213547-13@https.bugs.freebsd.org/bugzilla/> References: <bug-213547-13@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213547 --- Comment #6 from John Hein <z7dr6ut7gs@snkmail.com> --- (In reply to yuri from comment #5) The actual library that is "chosen during the build" depends on -L, -rpath = and (as you mentioned) possibly libraries specified with an absolute path. Since we're talking about dynamic linking, however, that's only half of the "linking" picture. At run time (or when you run ldd), the second part of the linking job is finished off and the library file that is chosen can be influenced by a num= ber of things, such as: - whether a run time "hint" was supplied at build time (-rpath) - LD_PRELOAD & LD_LIBRARY_PATH (if not setuid binaries unless you're root) - the ldconfig system search path With all the variables involved, there is more than one way to fool stage-q= a so that it doesn't necessarily find undocumented library dependencies. Given = the default system configuration, removing LD_LIBRARY_PATH from qa.sh removes o= ne reasonably likely potential false positive source, and leaving it there doe= sn't help find undeclared dependencies at all. --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-213547-13-F7lhoodkmd>