bug-gdb
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

AIX 5.3, gcc 4.3.1, gdb 6.8 build issues


From: pedz
Subject: AIX 5.3, gcc 4.3.1, gdb 6.8 build issues
Date: Sun, 27 Jul 2008 08:56:37 -0700 (PDT)
User-agent: G2/1.0

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]