From owner-freebsd-current Wed Jan 12 19: 0:11 2000 Delivered-To: freebsd-current@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id 7210C150AC for ; Wed, 12 Jan 2000 19:00:06 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.3) with ESMTP id TAA04987; Wed, 12 Jan 2000 19:00:02 -0800 (PST) (envelope-from jdp@polstra.com) From: John Polstra Received: (from jdp@localhost) by vashon.polstra.com (8.9.3/8.9.1) id TAA74514; Wed, 12 Jan 2000 19:00:01 -0800 (PST) (envelope-from jdp@polstra.com) Date: Wed, 12 Jan 2000 19:00:01 -0800 (PST) Message-Id: <200001130300.TAA74514@vashon.polstra.com> To: jasone@canonware.com Subject: Re: RFC: buildworld breakage due to cross-tools/libc/mktemp. In-Reply-To: <20000112172213.Z302@sturm.canonware.com> References: <20000112172213.Z302@sturm.canonware.com> Organization: Polstra & Co., Seattle, WA Cc: current@freebsd.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article <20000112172213.Z302@sturm.canonware.com>, Jason Evans wrote: > The buildworld problem that I introduced is due to cc_fbsd directly > compiling and linking in src/lib/libc/stdio/mktemp.c. This is in my > opinion a questionable practice, since it adds dependencies to the > internals of the libc code, which has just been proven to bite. =) Yes, I agree. > Aesthetics aside, I'm not sure what the best fix for the problem is. > Options include: > > 1) Ignore the problem, since it only happens once, and has a work-around. > This is probably not a good idea, since it makes the upgrade path > bumpy. Yes, please avoid this if at all possible. We've had too many of these "one-time" special procedures in the past year. Committers haven't been trying hard enough to avoid them, IMHO. The trouble with special upgrade procedures is that they linger for a year beyond when the problem began, as different users try upgrading and run into trouble. Also, they're a big PITA for system admins who have many machines to upgrade. > 2) Make a separate copy of mktemp.c to remove the internal dependency. I think this is the best approach -- likewise for getobjformat.c, which is also used currently. I _really_ don't like it when a program reaches waaaaaaay over into an unrelated directory for its sources. This isn't the first time it has caused unexpected problems. If you change the internals of a self-contained subtree, you should reasonably be able to assume that it won't break something on the other side of the source tree. I'd rather have a few duplicated sources. > I'm not familiar with the detailed semantics of mktemp() but > this may be a problem if mktemp() is required to behave the same > across all programs, and the two versions of mktemp.c diverge. I'd still rather have a few duplicated sources. > > 3) Add conditional compilation, such that the macro _libc_open=open is > defined during the cross-tools stage. I tried this, but wasn't able to > find an obvious way of inserting it into the build system. Besides, > it's a bit of a hack, and doesn't address the core issue (dependency on > libc internals). Right. Ick. > 4) Build a libc for the cross-tools stage that all the targets for that > stage can be linked against. This looks cleanest to me, but adds > substantially to build time and may be difficult to implement. 5) Maintainers of the build tools should be very careful to ensure that their tools use only the minimum, universally-available functionality from libc. That means (ideally) only functions which appear in the ANSI/ISO C standard, or (tolerably) only functions which appear in ANSI/ISO C or POSIX. This means: if you need a FreeBSD-specific function such as getobjformat() then you write your own version of it, or copy the source and maintain it separately, or look for a different approach. John -- John Polstra jdp@polstra.com John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message