[Bug target/16300] Bug in vendor /usr/include/net/if.h needs fixincluding
--- Comment #18 from skunk at iskunk dot org 2009-08-07 21:13 --- Confirmed correct fixincluding of if.h in the GCC 4.4.1 build. Ding, dong, this bug is dead! -- skunk at iskunk dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16300
[Bug target/16300] Bug in vendor /usr/include/net/if.h needs fixincluding
--- Comment #17 from bkorb at gnu dot org 2009-02-28 16:39 --- Bruce Korb left Veritas 3 years ago. It's called "Symantec" now anyway. -- bkorb at gnu dot org changed: What|Removed |Added CC|bkorb at veritas dot com|bkorb at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16300
[Bug target/16300] Bug in vendor /usr/include/net/if.h needs fixincluding
--- Comment #16 from skunk at iskunk dot org 2009-02-28 00:41 --- Building 4.3.3 fails with /usr/home/cport/tmp/bash ./libtool --tag=CXX --mode=compile /usr/home/cport/build/gcc-4.3.3-build-test/./gcc/xgcc -shared-libgcc -B/usr/home/cport/build/gcc-4.3.3-build-test/./gcc -nostdinc++ -L/usr/home/cport/build/gcc-4.3.3-build-test/alphaev56-dec-osf4.0g/libstdc++-v3/src -L/usr/home/cport/build/gcc-4.3.3-build-test/alphaev56-dec-osf4.0g/libstdc++-v3/src/.libs -B/usr/home/cport/tmp/GCC/alphaev56-dec-osf4.0g/bin/ -B/usr/home/cport/tmp/GCC/alphaev56-dec-osf4.0g/lib/ -isystem /usr/home/cport/tmp/GCC/alphaev56-dec-osf4.0g/include -isystem /usr/home/cport/tmp/GCC/alphaev56-dec-osf4.0g/sys-include -DHAVE_CONFIG_H -I. -I/tg/freeport/src/gcc/gcc--4.3.3/libjava -I./include -I./gcj -I/tg/freeport/src/gcc/gcc--4.3.3/libjava -Iinclude -I/tg/freeport/src/gcc/gcc--4.3.3/libjava/include -I/tg/freeport/src/gcc/gcc--4.3.3/libjava/classpath/include -Iclasspath/include -I/tg/freeport/src/gcc/gcc--4.3.3/libjava/classpath/native/fdlibm -I/tg/freeport/src/gcc/gcc--4.3.3/libjava/../boehm-gc/include -I../boehm-gc/include -I/tg/freeport/src/gcc/gcc--4.3.3/libjava/libltdl -I/tg/freeport/src/gcc/gcc--4.3.3/libjava/libltdl -I/tg/freeport/src/gcc/gcc--4.3.3/libjava/.././libjava/../gcc -I/tg/freeport/src/gcc/gcc--4.3.3/libjava/../zlib -I/tg/freeport/src/gcc/gcc--4.3.3/libjava/../libffi/include -I../libffi/include -fno-rtti -fnon-call-exceptions -pthread -fdollars-in-identifiers -Wswitch-enum -D_FILE_OFFSET_BITS=64 -mieee -Wextra -Wall -D_GNU_SOURCE -DPREFIX="\"/usr/home/cport/tmp/GCC\"" -DTOOLEXECLIBDIR="\"/usr/home/cport/tmp/GCC/lib/gcc/alphaev56-dec-osf4.0g/4.3.3\"" -DJAVA_HOME="\"/usr/home/cport/tmp/GCC\"" -DBOOT_CLASS_PATH="\"/usr/home/cport/tmp/GCC/share/java/libgcj-4.3.3.jar\"" -DJAVA_EXT_DIRS="\"/usr/home/cport/tmp/GCC/share/java/ext\"" -DGCJ_ENDORSED_DIRS="\"/usr/home/cport/tmp/GCC/share/java/gcj-endorsed\"" -DGCJ_VERSIONED_LIBDIR="\"/usr/home/cport/tmp/GCC/lib/gcj-4.3.3-9\"" -DPATH_SEPARATOR="\":\"" -DECJ_JAR_FILE="\"\"" -DLIBGCJ_DEFAULT_DATABASE="\"/usr/home/cport/tmp/GCC/lib/gcj-4.3.3-9/classmap.db\"" -DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL="\"gcj-4.3.3-9/classmap.db\"" -O2 -g -mieee -c -o java/net/natVMNetworkInterface.lo java/net/natVMNetworkInterface.cc libtool: compile: /usr/home/cport/build/gcc-4.3.3-build-test/./gcc/xgcc -shared-libgcc -B/usr/home/cport/build/gcc-4.3.3-build-test/./gcc -nostdinc++ -L/usr/home/cport/build/gcc-4.3.3-build-test/alphaev56-dec-osf4.0g/libstdc++-v3/src -L/usr/home/cport/build/gcc-4.3.3-build-test/alphaev56-dec-osf4.0g/libstdc++-v3/src/.libs -B/usr/home/cport/tmp/GCC/alphaev56-dec-osf4.0g/bin/ -B/usr/home/cport/tmp/GCC/alphaev56-dec-osf4.0g/lib/ -isystem /usr/home/cport/tmp/GCC/alphaev56-dec-osf4.0g/include -isystem /usr/home/cport/tmp/GCC/alphaev56-dec-osf4.0g/sys-include -DHAVE_CONFIG_H -I. -I/tg/freeport/src/gcc/gcc--4.3.3/libjava -I./include -I./gcj -I/tg/freeport/src/gcc/gcc--4.3.3/libjava -Iinclude -I/tg/freeport/src/gcc/gcc--4.3.3/libjava/include -I/tg/freeport/src/gcc/gcc--4.3.3/libjava/classpath/include -Iclasspath/include -I/tg/freeport/src/gcc/gcc--4.3.3/libjava/classpath/native/fdlibm -I/tg/freeport/src/gcc/gcc--4.3.3/libjava/../boehm-gc/include -I../boehm-gc/include -I/tg/freeport/src/gcc/gcc--4.3.3/libjava/libltdl -I/tg/freeport/src/gcc/gcc--4.3.3/libjava/libltdl -I/tg/freeport/src/gcc/gcc--4.3.3/libjava/.././libjava/../gcc -I/tg/freeport/src/gcc/gcc--4.3.3/libjava/../zlib -I/tg/freeport/src/gcc/gcc--4.3.3/libjava/../libffi/include -I../libffi/include -fno-rtti -fnon-call-exceptions -pthread -fdollars-in-identifiers -Wswitch-enum -D_FILE_OFFSET_BITS=64 -mieee -Wextra -Wall -D_GNU_SOURCE -DPREFIX=\"/usr/home/cport/tmp/GCC\" -DTOOLEXECLIBDIR=\"/usr/home/cport/tmp/GCC/lib/gcc/alphaev56-dec-osf4.0g/4.3.3\" -DJAVA_HOME=\"/usr/home/cport/tmp/GCC\" -DBOOT_CLASS_PATH=\"/usr/home/cport/tmp/GCC/share/java/libgcj-4.3.3.jar\" -DJAVA_EXT_DIRS=\"/usr/home/cport/tmp/GCC/share/java/ext\" -DGCJ_ENDORSED_DIRS=\"/usr/home/cport/tmp/GCC/share/java/gcj-endorsed\" -DGCJ_VERSIONED_LIBDIR=\"/usr/home/cport/tmp/GCC/lib/gcj-4.3.3-9\" -DPATH_SEPARATOR=\":\" -DECJ_JAR_FILE=\"\" -DLIBGCJ_DEFAULT_DATABASE=\"/usr/home/cport/tmp/GCC/lib/gcj-4.3.3-9/classmap.db\" -DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL=\"gcj-4.3.3-9/classmap.db\" -O2 -g -mieee -c java/net/natVMNetworkInterface.cc -DPIC -o java/net/natVMNetworkInterface.o In file included from java/net/natVMNetworkInterface.cc:35: /usr/include/net/if.h:144: error: expected ';' before '}' token /usr/include/net/if.h:144: error: expected `;' before '}' token gmake[3]: *** [java/net/natVMNetworkInterface.lo] Error 1 gmake[3]: Leaving directory `/mnt/scratch/build/gcc-4.3.3-build-test/alphaev56-dec-osf4.0g/libjava' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/mnt/scratch/build/gcc-4.3.3-build-test/alphaev56-dec-osf4.0g/libjava' gmake[1]: *** [all-target-libjava] Error 2 gmake[1]: Leaving directory `/mnt/scratch/build/gcc-4.3.3-build-test'
[Bug target/16300] Bug in vendor /usr/include/net/if.h needs fixincluding
--- Comment #15 from skunk at iskunk dot org 2007-02-01 17:18 --- This bug is still present in 3.4.6 Bruce or Giovanni, could one of you please apply this patch? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16300
[Bug target/16300] Bug in vendor /usr/include/net/if.h needs fixincluding
--- 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
[Bug target/16300] Bug in vendor /usr/include/net/if.h needs fixincluding
--- Additional Comments From skunk at iskunk dot org 2004-10-28 21:07 --- [EMAIL PROTECTED]:/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
[Bug target/16300] Bug in vendor /usr/include/net/if.h needs fixincluding
--- 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
[Bug target/16300] Bug in vendor /usr/include/net/if.h needs fixincluding
--- 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
[Bug target/16300] Bug in vendor /usr/include/net/if.h needs fixincluding
--- 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 + */ + 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 + */ + 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
[Bug target/16300] Bug in vendor /usr/include/net/if.h needs fixincluding
--- 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
[Bug target/16300] Bug in vendor /usr/include/net/if.h needs fixincluding
--- 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
[Bug target/16300] Bug in vendor /usr/include/net/if.h needs fixincluding
--- 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 [EMAIL PROTECTED], [EMAIL PROTECTED] and, > please, to me: [EMAIL PROTECTED] That means send me email if you are still having problems. Regards, Bruce -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16300
[Bug target/16300] Bug in vendor /usr/include/net/if.h needs fixincluding
--- 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
[Bug target/16300] Bug in vendor /usr/include/net/if.h needs fixincluding
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |giovannibajo at libero dot |dot org |it Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2004-10-15 23:44:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16300
[Bug target/16300] Bug in vendor /usr/include/net/if.h needs fixincluding
--- 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
[Bug target/16300] Bug in vendor /usr/include/net/if.h needs fixincluding
--- 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
[Bug target/16300] Bug in vendor /usr/include/net/if.h needs fixincluding
-- What|Removed |Added CC||giovannibajo at libero dot ||it http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16300
[Bug target/16300] Bug in vendor /usr/include/net/if.h needs fixincluding
--- 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