Date: Wed, 14 Jul 2021 17:33:55 +0000 From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 257190] net/samba413: missing -rpath on nss_wins.so.1? Message-ID: <bug-257190-7788@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D257190 Bug ID: 257190 Summary: net/samba413: missing -rpath on nss_wins.so.1? Product: Ports & Packages Version: Latest Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: Individual Port(s) Assignee: timur@FreeBSD.org Reporter: leres@freebsd.org Flags: maintainer-feedback?(timur@FreeBSD.org) Assignee: timur@FreeBSD.org I recently switched from netatalk3 to samba413 (for use as a time machine share) and I find that /usr/local/lib/nss_wins.so.1 is linked against many shared libraries in /usr/local/lib/samba4/private but is not linked with -rpath/LD_RUN_PATH: zinc 24 @ ldd /usr/local/lib/nss_wins.so.1 | fgrep found | head -3 libwinbind-client-samba4.so =3D> not found (0) libreplace-samba4.so =3D> not found (0) libutil-setid-samba4.so =3D> not found (0) I have a cron job that looks for a reports binaries and shared libraries th= at have this problem. Clearly samba works this way (presumably all binaries th= at use nss_wins.so.1 have the correct -rpath/LD_RUN_PATH) but is it unreasonab= le for me to have the expectation that nss_wins.so.1 to by itself be able to f= ind it's dependent shared libraries? --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-257190-7788>