🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: gnu.utils.bug
Article #923

libg++2.2, glibc1.05, gcc2.2.2 cross development glitches

#923
From: Robert R. Henry
Date: Wed, 14 Oct 1992 23:54
96 lines
7107 bytes
I am building a set of cross development tools
	host==sparc-sun-sunos4.1
	target==68k-sun-sunos4.1
I am having problems in the marriage between glibc-1.05 and libg++-2.2
in this cross development environment.

I managed to build and install without too much trouble (except for
glibc-1.05, for which I have already posted bugs) everything
in the suite of most recent GNU tools (gmake, gas, gcc, ginutils and glibc)
except for building libg++-2.2 in the pure GNU cross development
environment that I have set up.

It helps to review the directory structure that the cross development
gcc2.2.2 sets up, and what I have done with respect to that:
  /usr/local/new/lib/gcc-lib/m68k-sun-sunos4.1/2.2.2/include
	contains files exported by gcc, including stdtypes.h
  /usr/local/new/lib/gcc-lib/m68k-sun-sunos4.1/2.2.2/sys-include
	is assumed by gcc2.2.2 to be where cross development .h files
	go.  I have made this directory be a symbolic link to
	the directory /usr/local/new/glibc-1.05/include,
	which is where I told glibc-1.05 to install itself.
  /usr/local/new/lib/g++-include
	where the libg++ installs itself.

In the cross development environment /usr/include is not consulted
by gcc2.2.2, just as one expects.

Now then, the problems that I have encountered stem from collision
in definitions between glibc-1.05 (what's responsible for sys-include)
and between libg++-2.2 when I compile libg++-2.2 in its source directory
using the cross development tools.

0) The files sys-include/stddef (from glibc) and include/stddef (from gcc)
differ subtly, and in ways that prevented me from compiling libg++,
particularly regarding the right expansion for wchar_t.
I ended up removing the sys-include/stddef so that the include/stddef
was used instead; this allowed me to compile libg++, but I don't
know what that means for (re)compiling glibc.

1) glibc1.05 does not install a curses.h into its installation include
directory; this is curses.h is needed to compile Curses*.cc in libg++.

2) I think that glibc1.05 does not install a param.h nor a machine/param.h,
although this could be a botch on my part when I installed glibc1.05

3) the compiler complains at line 291 in libg++/src/math-68881.h
that one is assigning a double to an integer; this is weird,
since that's a return from the function double hypot of the value returned
from sqrt, which is apparently defined on the previous function to return
a double.

4) The shell script gen-params in libg++-2.2 makes a call to `nm'; if
the nm on the search path doesn't de mangle names in the same way that
gen-params expects to find for vtable definitions, then gen-params
fails.  I had to dummy up a nm that gen-params would find
that was the right nm; there should be some mechanism so that I
can override nm when I invoke make (viz, ``gmake NM=nm68k'', say).

5) There are lots of warnings involving redefinitions of `open' and `fcntl';
here's one instance:

gcc68k -g  -I.. -I../../../libg++/src -I../../../libg++/src/../iostream\
-I../../../libg++/src/../g++-include  -c ../../../libg++/src/CursesW.cc
In file included from /usr/local/new/lib/g++-include/fcntl.h:6, from ../../../libg++/src/../g++-include/fcntl.h:14, from ../../../libg++/src/std.h:31, from ../../../libg++/src/builtin.h:32, from ../../../libg++/src/CursesW.cc:22:
../../../libg++/src/../g++-include/fcntl.h:8: warning: this is the location of the previous definition
/usr/local/new/lib/gcc-lib/m68k-sun-sunos4.1/2.2.2/sys-include/fcntl.h:112: warning: `open' redefined
../../../libg++/src/../g++-include/fcntl.h:9: warning: this is the location of the previous definition

6) The defintion of ioctl differs between the two libraries:

In file included from /usr/local/new/lib/gcc-lib/m68k-sun-sunos4.1/2.2.2/sys-include/sgtty.h:23, from /usr/local/new/lib/gcc-lib/m68k-sun-sunos4.1/2.2.2/sys-include/curses.h:13, from /usr/local/new/lib/g++-include/curses.h:5, from ../../../libg++/src/../g++-include/curses.h:10, from ../../../libg++/src/CursesW.h:26, from ../../../libg++/src/CursesW.cc:30:
/usr/local/new/lib/gcc-lib/m68k-sun-sunos4.1/2.2.2/sys-include/sys/ioctl.h:109: conflicting types for `int  ioctl (int, int, void *)'
../../../libg++/src/../g++-include/unistd.h:103: previous declaration of `int  ioctl (int, int, ...)'

5) The defintion of `socket', `listen', `socketpair'
and other functions differs between the two libraries; here's only
a smattering:

../../../libg++/src/../g++-include/sys/socket.h:30: conflicting types for `int  listen (int, int)'
/usr/local/new/lib/gcc-lib/m68k-sun-sunos4.1/2.2.2/sys-include/sys/socket.h:239: previous declaration of `int  listen (int, unsigned int)'
../../../libg++/src/../g++-include/sys/socket.h:42: conflicting types for `int  socket (int, int, int)'
/usr/local/new/lib/gcc-lib/m68k-sun-sunos4.1/2.2.2/sys-include/sys/socket.h:102: previous declaration of `int  socket (int, enum __socket_type, int)'
../../../libg++/src/../g++-include/sys/socket.h:43: conflicting types for `int  socketpair (int, int, int, int *)'
/usr/local/new/lib/gcc-lib/m68k-sun-sunos4.1/2.2.2/sys-include/sys/socket.h:109: previous declaration of `int  socketpair (int, enum __socket_type, int, int *)'
In file included from ../../../libg++/src/osfcn.h:13, from ../../../libg++/src/timer.cc:34:
../../../libg++/src/../g++-include/sys/resource.h:20: conflicting types for `int  getrusage (int, struct rusage*)'
/usr/local/new/lib/gcc-lib/m68k-sun-sunos4.1/2.2.2/sys-include/sys/resource.h:135: previous declaration of `int  getrusage (enum __rusage_who, struct rusage*)'
../../../libg++/src/../g++-include/sys/resource.h:21: conflicting types for `int  getrlimit (int, struct rlimit*)'
/usr/local/new/lib/gcc-lib/m68k-sun-sunos4.1/2.2.2/sys-include/sys/resource.h:71: previous declaration of `int  getrlimit (enum __rlimit_resource, struct rlimit*)'
../../../libg++/src/../g++-include/sys/resource.h:24: conflicting types for `int  getpriority (int, int)'
/usr/local/new/lib/gcc-lib/m68k-sun-sunos4.1/2.2.2/sys-include/sys/resource.h:173: previous declaration of `int  getpriority (enum __priority_which, int)'
../../../libg++/src/../g++-include/sys/resource.h:25: conflicting types for `int  setpriority (int, int, int)'
-I../../../libg++/iostream/../g++-include -c  ../../../libg++/iostream/procbuf.C
In file included from ../../../libg++/iostream/procbuf.C:20:
../../../libg++/iostream/../g++-include/signal.h:45: conflicting types for `int (* ssignal (...))()'
/usr/local/new/lib/gcc-lib/m68k-sun-sunos4.1/2.2.2/sys-include/signal.h:76: previous declaration of `void (* ssignal (int, auto void (*)(int )))(int )'
Technical Details
Message-ID: <9210142354.AA15152@tera.com>
Path: arc1-ca.pugleaf.net!sparky!uunet!convex!linac!pacific.mps.ohio-state.edu!cis.ohio-state.edu!tera.com!rrh

Show Full Headers
Complete Article Headers
Newsgroups: gnu.utils.bug
Path: arc1-ca.pugleaf.net!sparky!uunet!convex!linac!pacific.mps.ohio-state.edu!cis.ohio-state.edu!tera.com!rrh
From: rrh@tera.com (Robert R. Henry)
Subject: libg++2.2, glibc1.05, gcc2.2.2 cross development glitches
Message-ID: <9210142354.AA15152@tera.com>
Sender: gnulists@ai.mit.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 14 Oct 1992 23:54:41 GMT
Approved: bug-gnu-utils@prep.ai.mit.edu
Lines: 97