In article <[EMAIL PROTECTED]>,
Jason Evans <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
John D. Polstra & Co., Inc. Seattle, Washington USA
"Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
