ports/177403: [patch] Mk/bsd.port.mk

[Glen Barber]

>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 at 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 at nucleus:/home/gjb # chroot /scratch/
    root at nucleus:/ # make -C /usr/ports -V OSVERSION
    901502
    root at 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)
 	- at 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: