| Newsgroups |
gmane.os.netbsd.devel.toolchain |
| Message-ID |
<[email protected]> |
Le Thu, May 11, 2023 at 09:45:07AM -0400, Greg Troxel a écrit :
> [email protected] writes:
>
> > And I fail to see why a constant rule should not be for the RT
> > linker to search first for /usr/lib:/lib, that is to forbid to mask
> > system libraries (perhaps a paxctl(8) feature) before resorting to
> > rpath or other means to set a series of paths to search. The only
> > possible scenario I can find for the need of masking system libraries
> > is someone having an executable and not the source code, unable to
> > relink it, while a dynamically shared library specified in the
> > executable matches a system one that does not work with the crucial
> > executable. But if there are rules this is precisely to allow explicit
> > exceptions.
>
> A common reason is to build against a pkgsrc version of a lib instead of
> base.
>
> Obviously some things are contentious, but it strikes me that two things
> you could do that are unlikely to get significant objections:
>
> - implement a program that say finds every binary in PATH and checks
> the RPATH entries, looking for some conditions you find unsafe and
> just print out results. Add this to pkgsrc so people can try it.
> Actual data on unsafe configurations found in the world would inform
> the discussion, and would help the paranoid patrol their systems.
>
At first, putting aside efficiency, a sh(1) prototype should be easy,
using simply file(1) and readelf(1).
> - Examine what pkgsrc is doing already. I would not be surprised to
> find that if a binary gets built with an RPATH outside of pkgsrc
> (and not base X and base base) that this is an error, but maybe only
> in developer mode. This might also surface some interesting data.
I will give a look at the way pkgsrc does things. But as usual, there is
BSD make and then the GNU autoconf/automake dance and then the upstream
idiosynchrasies, so it is probably simpler to test the result than to
trace the compilation process (well, if there is a wrong result, one can
focus afterwards on the way this one is built).
--
Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
http://www.kergis.com/
http://kertex.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89 250D 52B1 AE95 6006 F40C