🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

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
#923
Author: 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 )'
Re: libg++2.2, glibc1.05, gcc2.2.2 cross development glitches
#926
Author: bothner
Date: Wed, 14 Oct 1992 11:06
19 lines
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