Date: Wed, 27 Mar 2013 01:05:00 GMT From: Glen Barber <gjb@FreeBSD.org> To: freebsd-gnats-submit@FreeBSD.org Subject: ports/177403: [patch] Mk/bsd.port.mk Message-ID: <201303270105.r2R150n7041943@red.freebsd.org> Resent-Message-ID: <201303270110.r2R1A0oZ050822@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 177403
>Category: ports
>Synopsis: [patch] Mk/bsd.port.mk
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: freebsd-ports-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: change-request
>Submitter-Id: current-users
>Arrival-Date: Wed Mar 27 01:10:00 UTC 2013
>Closed-Date:
>Last-Modified:
>Originator: Glen Barber
>Release: 10.0-CURRENT r248659
>Organization:
>Environment:
FreeBSD nucleus 10.0-CURRENT FreeBSD 10.0-CURRENT #111 r248659: Sat Mar 23 16:49:27 EDT 2013 root@nucleus:/usr/obj/usr/src/sys/NUCLEUS amd64
>Description:
I have been tracking down an unusual build failure in certain cases, and
think I now have identified what is going wrong.
The problem is if building a release on a 10.0-CURRENT build host for
the stable/9 branch, during the port build phase for textproc/docproj,
the textproc/expat2 port would fail to create the libexpat.so.6 shared
library.
The 'run-autotools-fixup' target uses only OSVERSION. I think this is
only half of what is needed, in the case of chroot(8).
Consider the following scenario, where a stable/9 chroot is used on
a 10-CURRENT machine:
root@nucleus:/home/gjb # chroot /scratch/
root@nucleus:/ # make -C /usr/ports -V OSVERSION
901502
root@nucleus:/ # sysctl -n kern.osreldate
1000025
As OSVERSION is less than 1000000, the run-autotools-fixup target will
not run the fixup bits, so the build will fail because it is seen as
freebsd1.*, not freebsd10.*.
According to bsd.port.mk, OSVERSION is defined in this order:
1.) Value of __FreeBSD_version from /usr/include/sys/param.h
2.) Value of __FreeBSD_version from ${SRC_BASE}/sys/sys/param.h
3.) Value of kern.osreldate
The condition to run the fixup is:
.if ${OSVERSION} >= 1000000 && !defined(WITHOUT_FBSD10_FIX)
So, given a case where __FreeBSD_version and kern.osreldate can be
different, I think a more complete evaluation would be:
.if ${OSVERSION} >= 1000000 || ${KERNVERSION} >= 1000000 && \
!defined(WITHOUT_FBSD10_FIX)
The attached patch seems to solve the problem for me.
Requesting -exp run for attached patch.
>How-To-Repeat:
>Fix:
See attached patch.
Patch attached with submission follows:
Index: Mk/bsd.port.mk
===================================================================
--- Mk/bsd.port.mk (revision 314015)
+++ Mk/bsd.port.mk (working copy)
@@ -44,6 +44,7 @@
# "FreeBSD," "NetBSD," or "OpenBSD" as appropriate.
# OSREL - The release version (numeric) of the operating system.
# OSVERSION - The value of __FreeBSD_version.
+# KERNVERSION - The value of 'sysctl -n kern.osreldate'
#
# This is the beginning of the list of all variables that need to be
# defined in a port, listed in order that they should be included
@@ -1151,6 +1152,9 @@
.include "${PORTSDIR}/Mk/bsd.commands.mk"
+# Get FreeBSD kernel version
+KERNVERSION!= ${SYSCTL} -n kern.osreldate
+
#
# DESTDIR section to start a chrooted process if invoked with DESTDIR set
#
@@ -3683,7 +3687,8 @@
.if !target(run-autotools-fixup)
run-autotools-fixup:
# Work around an issue where FreeBSD 10.0 is detected as FreeBSD 1.x.
-.if ${OSVERSION} >= 1000000 && !defined(WITHOUT_FBSD10_FIX)
+.if ${OSVERSION} >= 1000000 || ${KERNVERSION} >= 1000000 && \
+ !defined(WITHOUT_FBSD10_FIX)
-@for f in `${FIND} ${WRKDIR} -type f \( -name config.libpath -o \
-name config.rpath -o -name configure -o -name libtool.m4 -o \
-name ltconfig -o -name libtool -o -name aclocal.m4 -o \
>Release-Note:
>Audit-Trail:
>Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201303270105.r2R150n7041943>