Skip site navigation (1)Skip section navigation (2)
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>