Date: Wed, 12 Jan 2000 19:00:01 -0800 (PST) From: John Polstra <jdp@polstra.com> To: jasone@canonware.com Cc: current@freebsd.org Subject: Re: RFC: buildworld breakage due to cross-tools/libc/mktemp. Message-ID: <200001130300.TAA74514@vashon.polstra.com> In-Reply-To: <20000112172213.Z302@sturm.canonware.com> References: <20000112172213.Z302@sturm.canonware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In article <20000112172213.Z302@sturm.canonware.com>, Jason Evans <jasone@canonware.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200001130300.TAA74514>