Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Installing libg++2.4 under NS3.1 with gcc 2.4.5

4 views
Skip to first unread message

Robert Nicholson

unread,
Sep 30, 1993, 3:27:17 PM9/30/93
to
Has anybody installed libg++2.4 under NS3.1 using gcc 2.4.5?

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)'

William Ching

unread,
Sep 30, 1993, 7:07:27 PM9/30/93
to
Robert Nicholson (rob...@steffi.demon.co.uk) wrote:
> Has anybody installed libg++2.4 under NS3.1 using gcc 2.4.5?

> [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"

Mike Henry

unread,
Oct 7, 1993, 9:35:28 AM10/7/93
to
In article <930930122...@steffi.demon.co.uk> Robert Nicholson <rob...@steffi.demon.co.uk> writes:
>Has anybody installed libg++2.4 under NS3.1 using gcc 2.4.5?
>
>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>
>}

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/

0 new messages