This is the mail archive of the
java-prs@gcc.gnu.org
mailing list for the Java project.
[Bug target/16300] Bug in vendor /usr/include/net/if.h needs fixincluding
- From: "bkorb at veritas dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: java-prs at gcc dot gnu dot org
- Date: 18 Oct 2004 05:06:20 -0000
- Subject: [Bug target/16300] Bug in vendor /usr/include/net/if.h needs fixincluding
- References: <20040630163127.16300.skunk@iskunk.org>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From bkorb at veritas dot com 2004-10-18 05:06 -------
Subject: Re: Bug in vendor /usr/include/net/if.h needs
fixincluding
giovannibajo at libero dot it wrote:
>
> ------- Additional Comments From giovannibajo at libero dot it 2004-10-16 03:30 -------
> CC'ing also Bruce because he's the fixincludes maintainer. Bruce, BTW, as a
> developer which digs for the first time in fixincludes, let me say that
> fixincludes/README is not very clear about how 'make check' is supposed to work.
I can only fix things about which I get feedback so it incrementally
gets better. I'm sorry you found it difficult.
> Also, it does not explain if it is possible (and how) to use the test_text to
> verify the correctness of the fix. When I run 'make check' I don't understand
> if my new hack is being tested or not, and if it is correct or not.
"test-text" should contain one or more examples of broken text that
needs to be fixed. "make check" will spin a file with that text in it
and run the "fixinc" program, then run a recursive "diff" between the
patched files and a set of example files. Any differences are highlighted.
So, when you make a fix, you should pretty well understand how the
broken text ought to be transformed. In the "make check", you ought
to see a diff that includes that new transform in the new output and
not in the sample output.
> 4. Rebuild the compiler and check the header causing the issue.
> Make sure it is now properly handled. Add tests to the
> "test_text" entry(ies) that validate your fix. This will
> help ensure that future fixes won't negate your work.
That means first, ensure the header you want fixed is fixed.
Then, incorporate the brokenness in the "text-text" field.
Then, ensure it is fixed in the sample output.
Then, add the fixed result into the baseline sample files.
Finally:
> If you are having some problem with a system header that is either
> broken by the manufacturer, or is broken by the fixinclude process,
> then you will need to alter or add information to the include fix
> definitions file, ``inclhack.def''. Please also send relevant
> information to gcc-bugs@gcc.gnu.org, gcc-patches@gcc.gnu.org and,
> please, to me: bkorb@gnu.org.
That means send me email if you are still having problems.
Regards, Bruce
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16300