Date: Sun, 22 Apr 2012 12:07:29 -0700 From: Garrett Cooper <yanegomi@gmail.com> To: Dimitry Andric <dim@FreeBSD.org> Cc: Jan Sieka <jps@semihalf.com>, Doug Barton <dougb@FreeBSD.org>, Current FreeBSD <freebsd-current@freebsd.org> Subject: Re: buildworld fails on FreeBSD 7.x for HEAD from 19.04.2012 Message-ID: <D5342A23-878F-4F48-8E8A-41203B0FF918@gmail.com> In-Reply-To: <4F944139.4070309@FreeBSD.org> References: <4F915384.6070308@semihalf.com> <4F919C50.70809@FreeBSD.org> <9B9312D3-489E-4EF1-85CB-0353024F6B94@gmail.com> <4F9428ED.6060902@FreeBSD.org> <3862F1CA-C1C8-49E6-B768-114A0A212496@gmail.com> <4F944139.4070309@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Apr 22, 2012, at 10:34 AM, Dimitry Andric wrote:
> Well, I wouldn't want to run autoconf during build, firstly because it
> is horribly slow, and second because the results will be less
> predictable. Maybe during the bootstrap stage, it would be =
acceptable.
Sure -- that seems reasonable.
> But even then, one of the configure scripts could fail due to too-old
> system components, and you would be SOL.
=85 but it would be a step forward from where things are currently at. =
I'm not sure how well tested "source upgrade" paths are, but being able =
to upgrade from the lowest supported version to the latest supported =
version, then upgrading to CURRENT (at the very least) would be nice.
> Usually, if something is arch-dependent in a config.h file, we simply
> surround it with #ifdefs.
Makes sense (assumption being that it can be controlled via the =
config.h/configure.{ac,in} file). However, jemalloc recently disproved =
this >_<.
> Apparently the file(1) build needs a 'mkmagic' tool, which generates
> .mgc files (the 'compiled' version of magic files). This requirement
> was originally added in r81845, more than 10 years ago.
I tested out removing libmagic from Makefile.inc1 and see that there's =
some dependency magic going on there where building the library failed.
> Yes, it might work, but there is no guarantee. I'm not sure if there =
is
> enough incentive to change this policy. It would potentially require =
a
> lot effort to make it always work.
Understood and I guess the ownness is upon the stakeholders to fix this, =
but there are a lot of companies that depend on things like this working =
(at least to reduce pain when doing source upgrades). This would =
probably be less of an issue for developers that use freebsd-update or =
for companies that roll their own freebsd-update (and servers). I have =
yet to run into a company that does this though (not saying there aren't =
groups that could or do do this, but it's not the standard path).
> I wasn't aware of any chroot hackery?
A publicly available example is available in FreeNAS ( =
http://freenas.svn.sourceforge.net/viewvc/freenas?view=3Drevision&revision=
=3D8193 ); the hangup is building packages for a target system that =
doesn't match the build host.
Cheers!
-Garrett=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D5342A23-878F-4F48-8E8A-41203B0FF918>