cvs commit: src/include stdio.h src/lib/libc/stdio clrerr.c
feof.c ferror.c fileno.c getc.c getchar.c local.h putc.c putchar.c
cokane at FreeBSD.org
Thu May 8 00:24:58 UTC 2008
On Thu, 2008-05-08 at 01:19 +0200, Kris Kennaway wrote:
> Alfred Perlstein wrote:
> > * John Baldwin <jhb at freebsd.org> [080507 10:28] wrote:
> >> On Wednesday 07 May 2008 02:40:13 am Alfred Perlstein wrote:
> >>> * John Baldwin <jhb at freebsd.org> [080505 13:47] wrote:
> >>>> On Monday 05 May 2008 03:24:17 pm Peter Jeremy wrote:
> >>>>> On Mon, May 05, 2008 at 02:59:28PM -0400, John Baldwin wrote:
> >>>>>> On Monday 05 May 2008 02:40:03 pm Alfred Perlstein wrote:
> >>>>>>> I'm _not_ objecting, just interested in why.
> >>>>>>> Any references to discussions on this? Are we now safe for
> >>>>>>> future compat or something?
> >>>>>> Having FILE be opaque broke just about every 'configure' script on the
> >>>>>> planet. :(
> >>>>> Either autoconf and friends are _intended_ as impediments to
> >>>>> portability or they are completely broken by design.
> >>>> It appears that autoconf only believes a type is real if you can typedef
> >> it to
> >>>> another type, cast 0 to a valid pointer to the new typedef'd type, and do
> >> a
> >>>> sizeof() of the typdef'd type. The last is where having an opaque type
> >>>> breaks down for scripts that want to make sure FILE is a real type.
> >>> Oh c'mon! we're going to revert this needed fix just because of
> >>> autoconf?
> >> Pretty much. It appears that FILE has been public for so long that there is a
> >> lot of code that assumes it can use it.
> > I don't think that's really fair, stdio has had adequate accessors
> > for a long time, if AN(*) application does the wrong thing for long enough
> > it does not make it right.
> > (*) Important note: when considering autoconf scripts, most of the
> > scripts test's come from a repository of scripts or are carbon
> > copied from each other. Saying that "all ports are broken" is not
> > true, it is a single suite of configuration scripts that are broken
> > and need fixing, then we will be OK.
> > We have precident here of hacked autoconf and ports build logic
> > that automatically "seds" various things in scripts. I think
> > a few knobs can fix this for us.
> The offer was a serious one. If you're interested in evaluating the
> impact of this change on ports then just say the word.
What if we fix this breakage through a patch in our autoconf/automake
and then put a toggle in the ports system that could be told to re-run
autogen on the offending ports before the configure script is run
(hopefully replacing the broken "configure" with one that works)?
On an embedded Linux system I am working with, I've been using this
approach to fix some "host machine arch not found" errors.
I would be able to live with ports being broken for a bit if it means we
can get the change in... I'd even put in some time that I can to help
fix the ones that I depend upon.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/cvs-src/attachments/20080508/e2ce99e3/attachment.pgp
More information about the cvs-src