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. Fix: See attached patch. Patch attached with submission follows:
Responsible Changed From-To: freebsd-ports-bugs->portmgr bsd.port.mk is portmgr territory (via the GNATS Auto Assign Tool)
Responsible Changed From-To: portmgr->miwi I'll take it.
I think at first glance that this is wrong. Building packages for stable/9 or whatever version of a HEAD release, in chroot/jail is what is done on poudriere/tinderbox by default and we never faced that problem. libexpat.so.6 should be built in that case, it would be first interesting to understand why it failed and why the configure script is thinking you are on FreeBSD 10 in that case and fix it. What I do think is that you haven't overwriter UNAME_p and UNAME_r and so one inside your chroot, meaning that uname -r is giving you 10.0-... which means that your package building will be all wrong (more that just that problem you faced). So I'm really against that patches which will hide the problem and more about perhaps documenting how a chroot/jail should be setup to be able to build proper packages by overriding UNAME_* regards, BApt
Responsible Changed From-To: miwi->portmgr back to portmgr, exp-run was fine, but bapt have some concern, awaiting submitter feedback.
On Fri, May 31, 2013 at 11:36:46AM +0200, Baptiste Daroussin wrote: > I think at first glance that this is wrong. > > Building packages for stable/9 or whatever version of a HEAD release, in > chroot/jail is what is done on poudriere/tinderbox by default and we never > faced that problem. > > libexpat.so.6 should be built in that case, it would be first interesting > to understand why it failed and why the configure script is thinking you > are on FreeBSD 10 in that case and fix it. > > What I do think is that you haven't overwriter UNAME_p and UNAME_r and so > one inside your chroot, meaning that uname -r is giving you 10.0-... which > means that your package building will be all wrong (more that just that > problem you faced). > > So I'm really against that patches which will hide the problem and more > about perhaps documenting how a chroot/jail should be setup to be able to > build proper packages by overriding UNAME_* > Sorry, I think this is the wrong approach. In all cases, /usr/src/sys/sys/param.h should override kern.osreldate, since src tree correlating to sys/sys/param.h is the environment under which the binary should run. Evaluating OSVERSION from sys/sys/param.h then wrongfully overriding with kern.osreldate is the wrong approach. Glen
Indeed. bapt's concerns are valid because = autoconf/perl/python/etc looks for uname when doing version checks, = which means it'll mess up on 10-CURRENT machines when building 9-STABLE = images :(=85 Part of the reason why I wrote this up for FreeNAS [1], = based on a post by ambrisko@ several years back. Thanks! -Garrett 1. http://sourceforge.net/p/freenas/code/HEAD/tree/trunk/nanobsd/common # NOTE: the following code consists of temporary shims inherited from = the # FreeNAS project to get things to work with the predefined src + ports = tree # pulled by do_build.sh to work with an untainted build environment. = This works # on amd64/i386, but not in other cross-architecture scenarios. # # The shims will be removed/folded into nanobsd.sh once a more generic = solution # is available for solving some of the problems with bsd.ports.mk = related to # cross-building, package-recursive build issues, etc. # XXX: chroot is not cross-architecture safe. fake_target_host() { local newvers revision branch newvers=3D"$NANO_SRC/sys/conf/newvers.sh" revision=3D$(grep -m 1 REVISION=3D $newvers | cut -f2 -d '"') branch=3D$(grep -m 1 BRANCH=3D $newvers | cut -f2 -d '"') # 1. Invoke a subshell so we don't pollute the build environment = with # these variables. # 2. Use sane defaults to avoid polluting the build environment = with # system specific settings that might have been defined via # /etc/make.conf (LOCALBASE), etc. ( set -e env export UNAME_m=3D$NANO_ARCH export UNAME_p=3D$NANO_ARCH export UNAME_r=3D"$revision-$branch" export UNAME_v=3D"$(uname -v | sed -e "s/$(uname -p)/$UNAME_p/" = -e "s/$(uname -r)/$UNAME_r/g")" export OSVERSION=3D$(awk '/\#define.*__FreeBSD_version/ { print = $3 }' "$NANO_SRC/sys/sys/param.h") export = PATH=3D${PBI_BINDIR}:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/lo= cal/bin "$@" ) }=
+1 to resolve this I ran stable/9 machine, and updated kernel to head to get 802.11n working. Since that I started to get failed port builds with shared libraries. Surprisingly, that was caused by that ./configure script gets osversion from uname, but our FBSD_10FIX first gets it from the sys/param.h installed in the system which are the different values. So, why WITH_FBSD10_FIX doesn't work on stable/9 world with 10 kernel? That is unfortunate. I am forced to manually hack on bsd.port.mk to always apply the configure fix. Probably we should always run that fix irrelevant to FreeBSD version. -- wbr, pluknet
Just make the FreeBSD 10 autoconf fixup unconditional. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no
Responsible Changed From-To: portmgr->bdrewery take for exp-run
State Changed From-To: open->closed Clearly no interest in fixing this. Since 9.3 will be the last stable/9 release, no sense in wasting effort here.