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 xprintf.c

[Coleman Kane]

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.
> 
> Kris
> 

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.

-- 
Coleman Kane
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part
Url : http://lists.freebsd.org/pipermail/cvs-src/attachments/20080508/e2ce99e3/attachment.pgp