Article View: gnu.utils.bug
Article #923libg++2.2, glibc1.05, gcc2.2.2 cross development glitches
From: Robert R. Henry
Date: Wed, 14 Oct 1992 23:54
Date: Wed, 14 Oct 1992 23:54
96 lines
7107 bytes
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!rrhShow 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