Date: Sun, 26 Aug 2018 11:24:04 -0600 From: Ian Lepore <ian@freebsd.org> To: rgrimes@freebsd.org Cc: Sean Bruno <sbruno@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r338330 - head/lib/libmd Message-ID: <1535304244.22114.3.camel@freebsd.org> In-Reply-To: <201808261715.w7QHFNkM006843@pdx.rh.CN85.dnsmgr.net> References: <201808261715.w7QHFNkM006843@pdx.rh.CN85.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 2018-08-26 at 10:15 -0700, Rodney W. Grimes wrote: > > > > On Sun, 2018-08-26 at 17:05 +0000, Sean Bruno wrote: > > > > > > Author: sbruno > > > Date: Sun Aug 26 17:05:43 2018 > > > New Revision: 338330 > > > URL: https://svnweb.freebsd.org/changeset/base/338330 > > > > > > Log: > > > ? r338270 had the side effect of no longer installing libmd.so > > > into /lib. > > > ? For users who have a seperate zfs mount of /usr or /usr/lib, > > > this will > > > ? cause dynamic loading failures when attempting to execute zfs > > > mount on > > > ? bootup. E.g. the system won't boot. > > > ?? > > > ? Including sets SHLIBDIR, so SHLIBDIR?= has no > > > ? effect.??The other lib/ Makefiles solve this problem by moving > > > the > > > ? SHLIBDIR??assignment to before .include . > > > ?? > > > ? Submitted by: jilles > > > ? Reviewed by: allanjude > > > ? Approved by: re (rgrimes) > > > ? Differential Revision: https://reviews.freebsd.org/D1691 > > > 0 > > > > > > Modified: > > > ? head/lib/libmd/Makefile > > > > > > Modified: head/lib/libmd/Makefile > > > ================================================================= > > > ============= > > > --- head/lib/libmd/Makefile Sun Aug 26 13:08:50 2018 > > > (r338329) > > > +++ head/lib/libmd/Makefile Sun Aug 26 17:05:43 2018 > > > (r338330) > > > @@ -1,11 +1,12 @@ > > > ?# $FreeBSD$ > > > ? > > > +SHLIBDIR?= /lib > > > + > > > ?.include > > > ? > > > ?PACKAGE=lib${LIB} > > > ?LIB= md > > > ?SHLIB_MAJOR= 6 > > > -SHLIBDIR?= /lib > > > ?SRCS= md4c.c md5c.c md4hl.c md5hl.c \ > > > ? rmd160c.c rmd160hl.c \ > > > ? sha0c.c sha0hl.c sha1c.c sha1hl.c \ > > > > > I'm curious why this is the preferred solution, as opposed to just > > leaving the assignment where it is and changing ?= to just =. > I think that reason would be that one could override > SHLIBDIR from a higher level, if they happened to > need to do that. Ie, I could build a FreeBSD release > that had SHLIBDIR=/usr/lib from the top level and > it would just work. (This can be done if you know > that / and /usr/lib well be in the same file system > for instance. I could also build SHLIBDIR=/lib and > forgo the need for /usr/lib. > Oh, hmm. I wasn't thinking of that as a knob that would be controllable from outside of the build system internals. IMO, that whole subject is a bit of a weakness of the freebsd build machinery... we don't define, either via documentation or (better, IMO) via consistant variable and target name prefixes, which things are intended to be user-settable controls and which are intended only for internal use. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1535304244.22114.3.camel>