Date: Wed, 12 Jan 2000 17:22:13 -0800 From: Jason Evans <jasone@canonware.com> To: current@freebsd.org Subject: RFC: buildworld breakage due to cross-tools/libc/mktemp. Message-ID: <20000112172213.Z302@sturm.canonware.com>
next in thread | raw e-mail | index | archive | help
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. =) 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. 2) Make a separate copy of mktemp.c to remove the internal dependency. 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. 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). 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. Suggestions are welcome. Jason 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?20000112172213.Z302>