Re: svn commit: r338330 - head/lib/libmd
> On Sun, 2018-08-26 at 10:15 -0700, Rodney W. Grimes wrote:
> > >
> > > On Sun, 2018-08-26 at 17:05 +, 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.
Back in the day it most of it was defined fairly well,
but over time as the complexity grew things have become
rather muddy.
I also suspect that there is probably some breakage if you
try to do what I mention above, but those are bugs that should
be fixed.
--
Rod Grimes rgri...@freebsd.org
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r338330 - head/lib/libmd
On Sun, 2018-08-26 at 10:15 -0700, Rodney W. Grimes wrote:
> >
> > On Sun, 2018-08-26 at 17:05 +, 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
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r338330 - head/lib/libmd
> On Sun, 2018-08-26 at 17:05 +, 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/D16910
> >
> > 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.
--
Rod Grimes rgri...@freebsd.org
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r338330 - head/lib/libmd
On 08/26/18 11:11, Ian Lepore wrote:
>> 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 =.
>
> -- Ian
>
>
I'm unsure if there is or isn't a preferred solution. There appear to
be multiple ways of doing this strewn about the tree.
This appears to be "a way" of fixing the state of -current at the
moment. I leave it to others more versed in the intricacies of Makefile
dark magic to scry a solution from the aether.
sean
signature.asc
Description: OpenPGP digital signature
Re: svn commit: r338330 - head/lib/libmd
On Sun, 2018-08-26 at 17:05 +, 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/D16910
>
> 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 =.
-- Ian
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r338330 - head/lib/libmd
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/D16910
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 \
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
