Thread View: gnu.utils.bug
2 messages
2 total messages
Started by Robert R. Henry
Wed, 14 Oct 1992 23:54
libg++2.2, glibc1.05, gcc2.2.2 cross development glitches
Author: 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 )'
Re: libg++2.2, glibc1.05, gcc2.2.2 cross development glitches
Author: bothner
Date: Wed, 14 Oct 1992 11:06
Date: Wed, 14 Oct 1992 11:06
19 lines
1205 bytes
1205 bytes
> 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). Well, there is, sort of: CONFIG_NM=my_nm make > 5) The defintion of `socket', `listen', `socketpair' > and other functions differs between the two libraries ... If glibc header files include the necessary 'extern "C"' declaration, you can kludge up libg++/configure.in to not use the files in libg++/g++-include at all. Look for: HAVE_CPLUS_EXTERN = 1 If you don't have 'extern "C"'in the header, hopefully gcc-2.3 will come with a script that generates these for you. --Per
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads