Re: [Bug-wget] wget-1.13 on AIX
Hi, On my 6.1 system I do not have flex so I removed the include from css.c and it compiled. On my 5.3 system I do have flex. Removing it from css.l worked as well. I am configuring --without-ssl but I'm assuming that will not make a difference for this. Thanks, Perry On Aug 12, 2011, at 10:20 AM, Giuseppe Scrivano wrote: Hello Perry, thanks to have reported it. Does it work correctly if you drop the #include wget.h line from css.l? === modified file 'src/css.l' --- src/css.l 2011-01-01 12:19:37 + +++ src/css.l 2011-08-12 15:18:23 + @@ -36,7 +36,6 @@ #define YY_NO_INPUT -#include wget.h #include css-tokens.h %} Thanks, Giuseppe Perry Smith pedz...@gmail.com writes: Hi, I've tried this on AIX 5.3 and 6.1. The problem is with src/css.c. In essence it is doing this: #include stdio.h #include string.h #include errno.h #include stdlib.h #include inttypes.h #define _LARGE_FILES #include unistd.h The #define of _LARGE_FILES is actually done in config.h via wget.h. I understand that AIX is very hard to deal with but this seems like a bad idea for any platform. If you are going to declare that you want _LARGE_FILE support, you need to do that before any system includes. What this causes is both _LARGE_FILES and _LARGE_FILE_API both get defined and that causes one place to declare (for example) #define ftruncate ftruncate64 (this is in unistd.h around line 733) and then later we have: extern int ftruncate(int, off_t); #ifdef _LARGE_FILE_API extern int ftruncate64(int, off64_t); #endif (around line 799) which the compiler complains about with: /usr/include/unistd.h:801: error: conflicting types for 'ftruncate64' /usr/include/unistd.h:799: error: previous declaration of 'ftruncate64' was here There are actually several pairs of these. With the above code snippet, if you move the #define to the top, (or completely remove it) the compile works fine. It just seems like it would be prudent to declare things like _LARGE_FILES in config.h (like you do) but put config.h as the first include of each file so that the entire code base knows which interface the program wants to use. What I did was to move css.c to _css.c. I put an #ifndef _CONFIG_H wrapper inside config.h and then the new css.c was simply: #include config.h #include _css.c and that worked for my 5.3 system. I have not tried it on my 6.1 system yet. I hope this helps someone. Thank you, pedz
[Bug-wget] wget-1.13 on AIX
Hi, I've tried this on AIX 5.3 and 6.1. The problem is with src/css.c. In essence it is doing this: #include stdio.h #include string.h #include errno.h #include stdlib.h #include inttypes.h #define _LARGE_FILES #include unistd.h The #define of _LARGE_FILES is actually done in config.h via wget.h. I understand that AIX is very hard to deal with but this seems like a bad idea for any platform. If you are going to declare that you want _LARGE_FILE support, you need to do that before any system includes. What this causes is both _LARGE_FILES and _LARGE_FILE_API both get defined and that causes one place to declare (for example) #define ftruncate ftruncate64 (this is in unistd.h around line 733) and then later we have: extern int ftruncate(int, off_t); #ifdef _LARGE_FILE_API extern int ftruncate64(int, off64_t); #endif (around line 799) which the compiler complains about with: /usr/include/unistd.h:801: error: conflicting types for 'ftruncate64' /usr/include/unistd.h:799: error: previous declaration of 'ftruncate64' was here There are actually several pairs of these. With the above code snippet, if you move the #define to the top, (or completely remove it) the compile works fine. It just seems like it would be prudent to declare things like _LARGE_FILES in config.h (like you do) but put config.h as the first include of each file so that the entire code base knows which interface the program wants to use. What I did was to move css.c to _css.c. I put an #ifndef _CONFIG_H wrapper inside config.h and then the new css.c was simply: #include config.h #include _css.c and that worked for my 5.3 system. I have not tried it on my 6.1 system yet. I hope this helps someone. Thank you, pedz
Re: [Bug-wget] wget-1.13 on AIX
Hello Perry, thanks to have reported it. Does it work correctly if you drop the #include wget.h line from css.l? === modified file 'src/css.l' --- src/css.l 2011-01-01 12:19:37 + +++ src/css.l 2011-08-12 15:18:23 + @@ -36,7 +36,6 @@ #define YY_NO_INPUT -#include wget.h #include css-tokens.h %} Thanks, Giuseppe Perry Smith pedz...@gmail.com writes: Hi, I've tried this on AIX 5.3 and 6.1. The problem is with src/css.c. In essence it is doing this: #include stdio.h #include string.h #include errno.h #include stdlib.h #include inttypes.h #define _LARGE_FILES #include unistd.h The #define of _LARGE_FILES is actually done in config.h via wget.h. I understand that AIX is very hard to deal with but this seems like a bad idea for any platform. If you are going to declare that you want _LARGE_FILE support, you need to do that before any system includes. What this causes is both _LARGE_FILES and _LARGE_FILE_API both get defined and that causes one place to declare (for example) #define ftruncate ftruncate64 (this is in unistd.h around line 733) and then later we have: extern int ftruncate(int, off_t); #ifdef _LARGE_FILE_API extern int ftruncate64(int, off64_t); #endif (around line 799) which the compiler complains about with: /usr/include/unistd.h:801: error: conflicting types for 'ftruncate64' /usr/include/unistd.h:799: error: previous declaration of 'ftruncate64' was here There are actually several pairs of these. With the above code snippet, if you move the #define to the top, (or completely remove it) the compile works fine. It just seems like it would be prudent to declare things like _LARGE_FILES in config.h (like you do) but put config.h as the first include of each file so that the entire code base knows which interface the program wants to use. What I did was to move css.c to _css.c. I put an #ifndef _CONFIG_H wrapper inside config.h and then the new css.c was simply: #include config.h #include _css.c and that worked for my 5.3 system. I have not tried it on my 6.1 system yet. I hope this helps someone. Thank you, pedz
