In NeXT's libg++2.3 the header file basically just included the
appropriate next header from from /usr/include
They basically looked like this (etc)
extern "C" {
#include <_G_config.h>
#include_next <unistd.h>
}
Now, in libg++2.4 there are prototypes as well as the instructions
necessary to import the appropriate next header files. Some of
these protoypes conflict with the default next prototypes in _their_
include files.
This is what it looks like in 2.4
#ifndef _G_unistd_h
#define _G_unistd_h 1
#include <_G_config.h>
extern "C" {
#if _G_HAVE_UNISTD
#ifndef _G_USE_PROTOS
#define chmod __hide_chmod
#define chown __hide_chown
#define execl __hide_execl
#define execlp __hide_execlp
#define execle __hide_execle
#define fchown __hide_fchown
#define ioctl __hide_ioctl
#define setgid __hide_setgid
#define setuid __hide_setuid
#endif
#ifdef _AIX
// AIX's unistd.h defines int rename (const char *old, const char *new).
// This is not legal ANSI. It causes a C++ syntax error (because of 'new').
#define new __new
#endif
#include_next <unistd.h>
#ifdef _AIX
#undef new
#endif
#ifndef _G_USE_PROTOS
#undef chmod
#undef chown
#undef execl
#undef execle
#undef execlp
#undef fchown
#undef ioctl
#undef setgid
#undef setuid
#endif
#else
#ifndef SEEK_SET
extern _G_pid_t setpgrp _G_ARGS((_G_pid_t, _G_pid_t));
#endif
extern int setregid _G_ARGS((int, int));
extern int setreuid _G_ARGS((int, int));
extern int setuid (_G_uid_t);
extern unsigned sleep _G_ARGS((unsigned));
extern void swab _G_ARGS((void*, void*, int));
extern int symlink _G_ARGS((const char*, const char*));
extern long sysconf _G_ARGS((int));
extern int truncate _G_ARGS((const char*, _G_off_t));
extern char* ttyname _G_ARGS((int));
extern int ttyslot _G_ARGS((void));
//extern int umask _G_ARGS((int)); /* commented out for now; wrong for SunOs4.
1 */
extern int unlink _G_ARGS((const char*));
extern _G_pid_t vfork _G_ARGS((void));
extern int vadvise _G_ARGS((int));
extern int vhangup _G_ARGS((void));
extern _G_off_t lseek _G_ARGS((int, long, int));
extern _G_ssize_t read _G_ARGS((int, void*, _G_size_t));
extern _G_ssize_t write _G_ARGS((int, const void*, _G_size_t));
extern int access _G_ARGS((const char*, int));
#ifndef hpux
extern int flock _G_ARGS((int, int));
#endif
}
#endif
Here's an example. (Should I just remove the prototypes from the .h file?
Is this what NeXT did in 2.3 or was that how 2.3 was distributed?)
root:/Users/robert/archives/libg++-2.4/libg++>make 10:46
Warning: TARGETLIB changed after being used
gcc -c -g -O -nostdinc++ -I. -I../. -I. -I./../iostream -I./../src -I./../g++-include procbuf.C
In file included from ioprivate.h:21, from procbuf.C:19:
./../g++-include/unistd.h:145: conflicting types for `long int read (...)'
/NextDeveloper/Headers/bsd/unistd.h:108: previous declaration of `int read (int, void *, long unsigned int)'
./../g++-include/unistd.h:146: conflicting types for `long int write (...)'
/NextDeveloper/Headers/bsd/unistd.h:121: previous declaration of `int write (int, const void *, long unsigned int)'
> [stuff deleted]
> Now, in libg++2.4 there are prototypes as well as the instructions
> necessary to import the appropriate next header files. Some of
> these protoypes conflict with the default next prototypes in _their_
> include files.
> This is what it looks like in 2.4
> #ifndef _G_unistd_h
> #define _G_unistd_h 1
> [quoted prototypes deleted]
> root:/Users/robert/archives/libg++-2.4/libg++>make 10:46
> Warning: TARGETLIB changed after being used
> gcc -c -g -O -nostdinc++ -I. -I../. -I. -I./../iostream -I./../src -I./../g++-include procbuf.C
> In file included from ioprivate.h:21, from procbuf.C:19:
> ./../g++-include/unistd.h:145: conflicting types for `long int read (...)'
> /NextDeveloper/Headers/bsd/unistd.h:108: previous declaration of `int read (int, void *, long unsigned int)'
> ./../g++-include/unistd.h:146: conflicting types for `long int write (...)'
> /NextDeveloper/Headers/bsd/unistd.h:121: previous declaration of `int write (int, const void *, long unsigned int)'
I solved the problem by simply manually executing that previous line, leaving
out the -I./../g++-include qualifier. Whether that results in an incorrect
library has yet to resolved, but I haven't seen any problem (YET)
-----------------------------------------------------------------------------
William Ching, System Administrator | wch...@csmt.music.yale.edu (NeXTMail)
Yale University Department of Music | Center for Studies in Music Technology
"To the insane the sane must seem insane"
I havent compiled libg++ 2.4 under NS, but this problem is similar to
the problems many people were having (including me) compiling it under
SunOS. The fix is to make sure and remove the file "_G_config.h" from
$GNUHOME/lib/g++-include since this file automagically created, and
also, under the new version it has been moved to
$GNUHOME/$ARCH/include for cross-compilation reasons.
Since it seems like you are trying to install the new version over an
old one, that means that the old _G_config.h wont be removed but
instead included before the new one, giving rise to frustrations at
best. The makers of libg++ suggest you totally wipe out old versions
before installing new ones. Dont blame me for this, however. B^)
-Mike
--
Mike Henry ///
ENEA DATA AB TEL : +46 8 638-5000 ///
Box 232 TFX : +46 8 638-5050 \\\///
S-183 23, SWEDEN INET : mi...@enea.se (NeXTmail OK) \XX/