From owner-svn-src-all@freebsd.org Sun Aug 26 17:24:18 2018 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9856C107C182 for ; Sun, 26 Aug 2018 17:24:18 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2230788BA7 for ; Sun, 26 Aug 2018 17:24:18 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: d531aba1-a954-11e8-aff6-0b9b8210da61 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id d531aba1-a954-11e8-aff6-0b9b8210da61; Sun, 26 Aug 2018 17:24:06 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w7QHO53C006034; Sun, 26 Aug 2018 11:24:05 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1535304244.22114.3.camel@freebsd.org> Subject: Re: svn commit: r338330 - head/lib/libmd From: Ian Lepore To: rgrimes@freebsd.org Cc: Sean Bruno , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Date: Sun, 26 Aug 2018 11:24:04 -0600 In-Reply-To: <201808261715.w7QHFNkM006843@pdx.rh.CN85.dnsmgr.net> References: <201808261715.w7QHFNkM006843@pdx.rh.CN85.dnsmgr.net> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Aug 2018 17:24:18 -0000 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