This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [patch] to gdb: portability fix: <sys/file.h>
- To: gdb-patches at sources dot redhat dot com
- Subject: Re: [patch] to gdb: portability fix: <sys/file.h>
- From: msokolov at ivan dot Harhan dot ORG (Michael Sokolov)
- Date: Tue, 6 Feb 01 15:01:33 PST
jtc@redback.com (J.T. Conklin) wrote:
> I'm puzzled what you mean by the Cygnus tree.
Please don't pretend that you don't know. I know all about your conspiracy.
ftp://ivan.Harhan.ORG/pub/embedded/cygnus-tree-intro
> If you mean that binutils, etc. add feature tests to each file that
> might need a macro definition, I say "great, if it works for them".
They use either that or a single file, usually called system.h, which does all
this and is included by everybody or almost everybody.
> While one way to interpret the gdb_*.h headers is to fix up broken
> headers, a broader (and IMO more useful) interpretation is that the
> gdb_*.h headers define a programming interface for the rest of GDB.
Then why have many gdb_*.h files rather than one system.h file? How would this
goo be divided between different gdb_*.h files? Why should the F_OK logic be in
gdb_unistd.h and not gdb_sys_file.h? Only because you politically favor systems
with this define in <unistd.h> over those with this define in <sys/file.h>?
If that's the route you want to take, someone else will have to do the work, as
I won't be qualified for this. For me true centerline UNIX == V7/4.3BSD, and if
you want to structure gdb's headers along the lines of SysV/POSIX/whatever, I
would have no idea and no desire to learn whether F_OK is supposed to be in
unistd.h or in fcntl.h or wherever by your "standards".
But in the meantime I want gdb to build on 4.3BSD.
> But I want to see what Andrew &
> others think.
Guys?
--
Michael Sokolov
Public Service Agent
International Engineering and Science Task Force
1351 VINE AVE APT 27 Phone: +1-714-738-5409
FULLERTON CA 92833-4291 USA (home office)
E-mail: msokolov@ivan.Harhan.ORG (ARPA TCP/SMTP)