* [Bug target/16300] Bug in vendor /usr/include/net/if.h needs fixincluding
2004-06-30 16:39 [Bug libgcj/16300] New: Bug in vendor /usr/include/net/if.h needs fixincluding skunk at iskunk dot org
@ 2004-07-01 1:17 ` pinskia at gcc dot gnu dot org
2004-10-13 12:52 ` giovannibajo at libero dot it
` (13 subsequent siblings)
14 siblings, 0 replies; 20+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-07-01 1:17 UTC (permalink / raw)
To: gcc-bugs
--
What |Removed |Added
----------------------------------------------------------------------------
Component|libgcj |target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16300
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug target/16300] Bug in vendor /usr/include/net/if.h needs fixincluding
2004-06-30 16:39 [Bug libgcj/16300] New: Bug in vendor /usr/include/net/if.h needs fixincluding skunk at iskunk dot org
2004-07-01 1:17 ` [Bug target/16300] " pinskia at gcc dot gnu dot org
@ 2004-10-13 12:52 ` giovannibajo at libero dot it
2004-10-13 13:04 ` giovannibajo at libero dot it
` (12 subsequent siblings)
14 siblings, 0 replies; 20+ messages in thread
From: giovannibajo at libero dot it @ 2004-10-13 12:52 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From giovannibajo at libero dot it 2004-10-13 12:51 -------
Daniel,
since you have access to the system, would you kindly attempt preparing a
fixinclude patch yourself? I guess it's easier for you to verify. If this is
impossible for you, please at least attacch a copy of the buggy if.h to this
report.
Thanks
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16300
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug target/16300] Bug in vendor /usr/include/net/if.h needs fixincluding
2004-06-30 16:39 [Bug libgcj/16300] New: Bug in vendor /usr/include/net/if.h needs fixincluding skunk at iskunk dot org
2004-07-01 1:17 ` [Bug target/16300] " pinskia at gcc dot gnu dot org
2004-10-13 12:52 ` giovannibajo at libero dot it
@ 2004-10-13 13:04 ` giovannibajo at libero dot it
2004-10-15 22:25 ` skunk at iskunk dot org
` (11 subsequent siblings)
14 siblings, 0 replies; 20+ messages in thread
From: giovannibajo at libero dot it @ 2004-10-13 13:04 UTC (permalink / raw)
To: gcc-bugs
--
What |Removed |Added
----------------------------------------------------------------------------
CC| |giovannibajo at libero dot
| |it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16300
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug target/16300] Bug in vendor /usr/include/net/if.h needs fixincluding
2004-06-30 16:39 [Bug libgcj/16300] New: Bug in vendor /usr/include/net/if.h needs fixincluding skunk at iskunk dot org
` (2 preceding siblings ...)
2004-10-13 13:04 ` giovannibajo at libero dot it
@ 2004-10-15 22:25 ` skunk at iskunk dot org
2004-10-15 23:43 ` giovannibajo at libero dot it
` (10 subsequent siblings)
14 siblings, 0 replies; 20+ messages in thread
From: skunk at iskunk dot org @ 2004-10-15 22:25 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From skunk at iskunk dot org 2004-10-15 22:25 -------
Created an attachment (id=7360)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7360&action=view)
/usr/include/net/if.h from Tru64
As I am not familiar with the inclhack.def syntax, I am attaching an unmodified
copy of Tru64's /usr/include/net/if.h system header file.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16300
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug target/16300] Bug in vendor /usr/include/net/if.h needs fixincluding
2004-06-30 16:39 [Bug libgcj/16300] New: Bug in vendor /usr/include/net/if.h needs fixincluding skunk at iskunk dot org
` (3 preceding siblings ...)
2004-10-15 22:25 ` skunk at iskunk dot org
@ 2004-10-15 23:43 ` giovannibajo at libero dot it
2004-10-15 23:44 ` giovannibajo at libero dot it
` (9 subsequent siblings)
14 siblings, 0 replies; 20+ messages in thread
From: giovannibajo at libero dot it @ 2004-10-15 23:43 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From giovannibajo at libero dot it 2004-10-15 23:43 -------
Created an attachment (id=7361)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7361&action=view)
Tentative patch
Can you try if this patch fixes it? Otherwise, you could try tweaking it a
little bit, if you are familiar with regular expressions. It should not be too
hard.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16300
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug target/16300] Bug in vendor /usr/include/net/if.h needs fixincluding
2004-06-30 16:39 [Bug libgcj/16300] New: Bug in vendor /usr/include/net/if.h needs fixincluding skunk at iskunk dot org
` (4 preceding siblings ...)
2004-10-15 23:43 ` giovannibajo at libero dot it
@ 2004-10-15 23:44 ` giovannibajo at libero dot it
2004-10-16 3:30 ` giovannibajo at libero dot it
` (8 subsequent siblings)
14 siblings, 0 replies; 20+ messages in thread
From: giovannibajo at libero dot it @ 2004-10-15 23:44 UTC (permalink / raw)
To: gcc-bugs
--
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|unassigned at gcc dot gnu |giovannibajo at libero dot
|dot org |it
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed| |1
Last reconfirmed|0000-00-00 00:00:00 |2004-10-15 23:44:09
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16300
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug target/16300] Bug in vendor /usr/include/net/if.h needs fixincluding
2004-06-30 16:39 [Bug libgcj/16300] New: Bug in vendor /usr/include/net/if.h needs fixincluding skunk at iskunk dot org
` (5 preceding siblings ...)
2004-10-15 23:44 ` giovannibajo at libero dot it
@ 2004-10-16 3:30 ` giovannibajo at libero dot it
2004-10-18 5:06 ` bkorb at veritas dot com
` (7 subsequent siblings)
14 siblings, 0 replies; 20+ messages in thread
From: giovannibajo at libero dot it @ 2004-10-16 3:30 UTC (permalink / raw)
To: gcc-bugs
------- 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.
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.
--
What |Removed |Added
----------------------------------------------------------------------------
CC| |bkorb at veritas dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16300
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug target/16300] Bug in vendor /usr/include/net/if.h needs fixincluding
2004-06-30 16:39 [Bug libgcj/16300] New: Bug in vendor /usr/include/net/if.h needs fixincluding skunk at iskunk dot org
` (6 preceding siblings ...)
2004-10-16 3:30 ` giovannibajo at libero dot it
@ 2004-10-18 5:06 ` bkorb at veritas dot com
2004-10-18 13:37 ` giovannibajo at libero dot it
` (6 subsequent siblings)
14 siblings, 0 replies; 20+ messages in thread
From: bkorb at veritas dot com @ 2004-10-18 5:06 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug target/16300] Bug in vendor /usr/include/net/if.h needs fixincluding
2004-06-30 16:39 [Bug libgcj/16300] New: Bug in vendor /usr/include/net/if.h needs fixincluding skunk at iskunk dot org
` (7 preceding siblings ...)
2004-10-18 5:06 ` bkorb at veritas dot com
@ 2004-10-18 13:37 ` giovannibajo at libero dot it
2004-10-18 15:16 ` skunk at iskunk dot org
` (5 subsequent siblings)
14 siblings, 0 replies; 20+ messages in thread
From: giovannibajo at libero dot it @ 2004-10-18 13:37 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From giovannibajo at libero dot it 2004-10-18 13:37 -------
Subject: Re: Bug in vendor /usr/include/net/if.h needs fixincluding
Bruce Korb wrote:
>> I can only fix things about which I get feedback so it
>> incrementally gets better. I'm sorry you found it difficult.
Sure, I did not want to sound offensive.
>> 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.
I still do not understand. The diff is being performed between the patched file
and what example files? If I add a new fix, should I also put a patched
(correct) version in the set of example files (where are they)?
> 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.
Now I am confused. I do not understand which of the following holds true:
- The diff shows what fixinclude did. It shows the different between the
original version (extracted from test-text) and the version that fixinclude
produced by applying your diff.
- The diff shows the mistakes of fixinclude, if any. It shows the different
between what fixinclude produced as output (by applying your fix to the
test-text) and what it is the expected result (which you have to put in a
different file -- where? how?).
>> 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.
This process can be done if you have physical access to the host with the
broken header. In my case, I was developing a fixinclude for a broken header
for another system. I have the broken header as a file (attacched to the bug).
How can I test my fix in this situation?
BTW: "rebuild the compiler" is a tad too much as first quick test for a
fixinclude (e.g. check that the regulard expression does not have a typo or
so). Even assuming access to the host, would you please explain if there is a
quicker wasy to just run fixincludes without rebuilding everything? Of course,
a full bootstrap would be still required as a final check.
> That means send me email if you are still having problems.
Thanks
Giovanni Bajo
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16300
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug target/16300] Bug in vendor /usr/include/net/if.h needs fixincluding
2004-06-30 16:39 [Bug libgcj/16300] New: Bug in vendor /usr/include/net/if.h needs fixincluding skunk at iskunk dot org
` (8 preceding siblings ...)
2004-10-18 13:37 ` giovannibajo at libero dot it
@ 2004-10-18 15:16 ` skunk at iskunk dot org
2004-10-18 16:06 ` bkorb at veritas dot com
` (4 subsequent siblings)
14 siblings, 0 replies; 20+ messages in thread
From: skunk at iskunk dot org @ 2004-10-18 15:16 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From skunk at iskunk dot org 2004-10-18 15:16 -------
The build still fails with the patched inclhack.def (same error, same place).
fixincludes does not appear to have patched the header in question; there is no
if.h present in the build tree.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16300
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug target/16300] Bug in vendor /usr/include/net/if.h needs fixincluding
2004-06-30 16:39 [Bug libgcj/16300] New: Bug in vendor /usr/include/net/if.h needs fixincluding skunk at iskunk dot org
` (9 preceding siblings ...)
2004-10-18 15:16 ` skunk at iskunk dot org
@ 2004-10-18 16:06 ` bkorb at veritas dot com
2004-10-20 20:14 ` skunk at iskunk dot org
` (3 subsequent siblings)
14 siblings, 0 replies; 20+ messages in thread
From: bkorb at veritas dot com @ 2004-10-18 16:06 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From bkorb at veritas dot com 2004-10-18 16:06 -------
Subject: Re: Bug in vendor /usr/include/net/if.h needs
fixincluding
skunk at iskunk dot org wrote:
>
> ------- Additional Comments From skunk at iskunk dot org 2004-10-18 15:16 -------
> The build still fails ...
/*
+ * Fix missing semicolon on Alpha OSF/4 in <net/if.h>
+ */
+ fix = {
+ hackname = alpha_if_semicolon;
+ files = "if.h";
+ select = "(struct[ \t]+sockaddr[ \t]+vmif_paddr)([ \t])([ \t]+/\*)";
+ c_fix = format;
+ c_fix_arg = "%1;%2%3";
+ test_text = ' struct sockaddr vmif_paddr /* protocol address */';
+ };
+
+
+ /*
* Remove erroneous parentheses in sym.h on Alpha OSF/1.
*/
fix = {
The select clause requires two white space characters
between "vmif_paddr" and "/*". Eliminate the unnecessary
subexpression stuff, thus:
/*
+ * Fix missing semicolon on Alpha OSF/4 in <net/if.h>
+ */
+ fix = {
+ hackname = alpha_if_semicolon;
+ files = "if.h";
+ select = "struct[ \t]+sockaddr[ \t]+vmif_paddr[ \t]+/\*";
+ c_fix = format;
+ c_fix_arg = "struct sockaddr vmif_paddr;\t/*";
+ test_text = ' struct sockaddr vmif_paddr /* protocol address */';
+ };
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16300
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug target/16300] Bug in vendor /usr/include/net/if.h needs fixincluding
2004-06-30 16:39 [Bug libgcj/16300] New: Bug in vendor /usr/include/net/if.h needs fixincluding skunk at iskunk dot org
` (10 preceding siblings ...)
2004-10-18 16:06 ` bkorb at veritas dot com
@ 2004-10-20 20:14 ` skunk at iskunk dot org
2004-10-20 20:23 ` bkorb at veritas dot com
` (2 subsequent siblings)
14 siblings, 0 replies; 20+ messages in thread
From: skunk at iskunk dot org @ 2004-10-20 20:14 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From skunk at iskunk dot org 2004-10-20 20:14 -------
Tried a new build, with the second patch given in comment #8; same failure mode
as before.
bkorb, are there embedded tabs in your patch? I can't pull it out of the comment
without expanding them; perhaps a patch-attachment would come through better?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16300
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug target/16300] Bug in vendor /usr/include/net/if.h needs fixincluding
2004-06-30 16:39 [Bug libgcj/16300] New: Bug in vendor /usr/include/net/if.h needs fixincluding skunk at iskunk dot org
` (11 preceding siblings ...)
2004-10-20 20:14 ` skunk at iskunk dot org
@ 2004-10-20 20:23 ` bkorb at veritas dot com
2004-10-28 21:07 ` skunk at iskunk dot org
2004-10-29 1:31 ` giovannibajo at libero dot it
14 siblings, 0 replies; 20+ messages in thread
From: bkorb at veritas dot com @ 2004-10-20 20:23 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From bkorb at veritas dot com 2004-10-20 20:22 -------
Subject: Re: Bug in vendor /usr/include/net/if.h needs
fixincluding
skunk at iskunk dot org wrote:
>
> ------- Additional Comments From skunk at iskunk dot org 2004-10-20 20:14 -------
> Tried a new build, with the second patch given in comment #8; same failure mode
> as before.
>
> bkorb, are there embedded tabs in your patch? I can't pull it out of the comment
> without expanding them; perhaps a patch-attachment would come through better?
Should make no difference, as there are no embedded tabs.
Well, there might be in the "test-text", but ``[ \t]+'' should match either.
What does the fix expand to in fixincl.x?
Regards, Bruce
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16300
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug target/16300] Bug in vendor /usr/include/net/if.h needs fixincluding
2004-06-30 16:39 [Bug libgcj/16300] New: Bug in vendor /usr/include/net/if.h needs fixincluding skunk at iskunk dot org
` (12 preceding siblings ...)
2004-10-20 20:23 ` bkorb at veritas dot com
@ 2004-10-28 21:07 ` skunk at iskunk dot org
2004-10-29 1:31 ` giovannibajo at libero dot it
14 siblings, 0 replies; 20+ messages in thread
From: skunk at iskunk dot org @ 2004-10-28 21:07 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From skunk at iskunk dot org 2004-10-28 21:07 -------
cport@drum:/mnt/scratch/gcc-3.4.2-build> find . -name if.h
./gcc/include/root/usr/sys/include/net/if.h
Yes, that does appear to be it---the header needs to be specified as "net/if.h"
instead of merely "if.h". Confirmed appropriate modification of if.h with diff(1).
(GCC still isn't building, but now it's an unrelated issue, i.e. /usr/bin/ld
complaining about multiply defined pthread symbols....)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16300
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug target/16300] Bug in vendor /usr/include/net/if.h needs fixincluding
2004-06-30 16:39 [Bug libgcj/16300] New: Bug in vendor /usr/include/net/if.h needs fixincluding skunk at iskunk dot org
` (13 preceding siblings ...)
2004-10-28 21:07 ` skunk at iskunk dot org
@ 2004-10-29 1:31 ` giovannibajo at libero dot it
14 siblings, 0 replies; 20+ messages in thread
From: giovannibajo at libero dot it @ 2004-10-29 1:31 UTC (permalink / raw)
To: gcc-bugs
------- Additional Comments From giovannibajo at libero dot it 2004-10-29 01:31 -------
> Yes, that does appear to be it---the header needs
> to be specified as "net/if.h" instead of merely "if.h".
Ok. Bruce, I guess this is more material for you to add to the documentation.
Will you take care of committing the final patch please?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16300
^ permalink raw reply [flat|nested] 20+ messages in thread