Two issues. Both, perhaps, could be argued are IBM's but they are not likely to change very quickly.
To cut to the chase, I got gdb 6.8 to compile and run on AIX 5.3 (5300-05-CSP-0000), running gcc 4.3.1 by adding these two lines to be bottom of my gdb/config.h file: #define lseek lseek64 #define clear() wclear(stdscr) The first happens because _LONG_LONG is defined. standards.h decides that since that is defined _LARGE_FILE_API should be defined but does not define _LARGE_FILES_. Later in unistd.h, if _LARGE_FILES_ is defined (which it is not), lseek is defined to call lseek64. Then a bit later if _LARGE_FILE_API is define (which it is), then the prototype of lseek is not defined. Instead the prototype of lseek64 is defined. A proper fix for gdb might be to test and see if you can call lseek and if you can not see if you can call lseek64. Note that the error happens because the compile has on some strict warning checks and lseek does not have a prototype at the time it is used in a few files. The second, just seems to be an oversight but IBM. With the defines that were being used in the compile, a big batch of #defines are hit (starting around line 1017 of curses.h). For example, that batch defines refresh to be wrefresh(stdscr). There is no define in that batch for clear. One suggestion I was going to make to FSF in general (this may be better placed in the gcc mailing lists). But, have you considered picking a standard such as XOPEN or POSIX or ... Then, with AIX in particular, define the appropriate symbol (like _XOPEN_SOURCE) which forces AIX to be XOPEN conformant. Many of the issues that I've seen with open source software on AIX is AIX is trying to please everyone (BSD, System V, Posix, XOpen, ... the list is endless) all at the same time and somewhere something clashes. My thought is if that was done by gcc (for example), then a lot of the portability issues would be avoided. _______________________________________________ bug-gdb mailing list bug-gdb@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gdb