Re: problems cross-compilng gcc

[Kai Ruottu <karuottu at freenet dot hut dot fi>]

Andy wrote:
> 
> did a make clean
> and then make all install in the gcc-2.95.2 directory
> 
> During biild there were several errors,:
> 1.couldn't find config files for ppc platform ( in gcc*/gcc/config/rs6000)
> Found them in src/gnu/egcs/gcc/config/rs6000

 So gcc-2.95.2 sources didn't have them but your OpenBSD sources did have them
(but for some earlier egcs version) and they could be used unchanged with the
gcc-2.95.2 sources?

 This seems however to be quite common situation. BSDI, FreeBSD and many Cygnus
ported targets seem also to have their config files only in their own sources.
The targets may be fully supported in binutils and GDB, but have no support in
GCC... Copying the config entry (into gcc/configure) and the config files it
uses into the proper directories will 'add' the target support for gcc-2.95.2,
perhaps some macros in the config files must be fixed, but after this the build
will seem to succeed.

Whether the resulted compiler then works or not, is however unclear...

> and copied  them to  gcc*/gcc/config/rs6000
> the files it was missing were:
> openbsd.h
> t-openbsd
> xm-openbsd.h
> 
> 2. confilicting types for sys_errlist in gcc*/powerpc--openbsd/
> libiberty/strerror.c
> Turns out it checks for a flag HAVE_SYS_ERRLIST that is never defined and
> redefines the variable sys_errlist.

 It failed to find the symbol 'sys_errlist' in 'libc.a'... (Probably because the
'libc.a' wasn't available when configuring. Running 'make clean' doesn't remove
the results from configure, like 'config.h')

> 3. PATH_MAX undefined in in gcc*/powerpc--openbsd/ libchill/basicio.c

 GCC has its own 'limits.h', which doesn't have the PATH_MAX.  I usually copy the
target system's own 'limits.h', which has it, into 'syslimits.h' in the 'gcc/include'
(overwriting the GCCs own 'dummy' version) and add a '#include <syslimits.h>' in the
beginning of the GCCs 'limits.h', when getting this error.

> 4. gcc*/ libiberty/strsignal.c:
> void psignal (signo, message)
>   unsigned signo;
>  char *message;
> the second parameter defined as const in the headers

 The GNU libc has also the 'const' in the 'psignal()' prototype. But if your headers
have it, you also have it in your 'libc.a' and adding it to 'libiberty.a' is vain. The
'gcc*/powerpc--openbsd/libiberty/config.h' should have something like '#define HAVE_PSIGNAL'
after the successfull configure, and then it would not compile psignal() for libiberty. 

> After that  I had no errors - build and install completed.
> So far so good
> Now on to build a powerpc kernel with the cross-compiler.
> Everything compiles but in the link phase I unresolved references ot bzero
> and bcomp ( which are declared in /src/sys/sys/systm.h/
> now the questions:
> 1. Obviously : where are bzero and bcmp defined ?

You have them in 'libbsd.a' or something, they are those obsolete BSD functions. And they
may be compiled for including them into 'libiberty.a'. But usually they are redefined in
some header.

The 'void * bzero(void *block, size_t size)' is normally redefined using memset():

    #define bzero(b,s) memset(b,0,s)

And the

  int bcmp(const void *a1, const void *a2, size_t size)

is just the same as the new

 int memcmp(const void *a1, const void *a2, size_t size)

Also bcopy() is normally redefined using memmove().

Basically these functions shouldn't be used any more in new code, but old sources
may still have them.

> 2. from the description above do i have a functional cross- compiler or am
> I missing something?

I would suggest finding someone with a working OpenBSD/PowerPC system and willing
to run some cross-compiled simple test programs first, just to make sure that it
really produces working executables. Trying the kernel first sounds too demanding.

But when the 'copy config files from some older release and build the new release using
them'-method has been used, and the new compiler can build 'libgcc.a', 'libiberty.a'
'libobjc.a', 'libstdc++.a' etc. without crashing with an internal error, this is quite
promising. Normally the internal errors etc. problems come already in these phases...

For example the Zilog Z8000, 'z8k', config files exist in the Cygnus eCos-1.21 sources
(from 990319), but copying these to egcs-1.1.2 (990314) and gcc-2.95.2 sources and
fixing some macros while building, produces compilers which crash with internal errors
while trying for the first time (to produce the SYSCALLS.c.X) in both cases... I had a
seemingly working compiler under Linux and Win32 :

E:\usr\local\samples>gcc-z8k -v
Reading specs from /usr/local/lib/gcc-lib/z8k-coff/2_7_2_c/specs
gcc version cygnus-2.7.2-970404

which I thought to upgrade... But now I think it may remain as the 'last which worked'.
Not much reason to get it fixed...

Ok, if the OpenBSD/PowerPC was 'officially' supported in some egcs-version, I would
suggest building that too. After building gcc-2.95.2, another more should be just a
piece of cake...  All the target libs (besides those built with GCC/egcs) and headers,
and the binutils will be common for both, but the xgcc/g++/gcov/c++filt/*protoize must
be named differently while installing, if wanting to keep them for both versions. Of
course the '--prefix=....' and '--target=....' must be the same as for gcc-2.95.2 when
configuring, so it finds the binutils, libs and headers from the same places.

 You could name the GCC-driver in the egcs-version as 'powerpc--openbsd-egcs' (and
keep the name 'powerpc--openbsd-gcc' for the gcc-2.95.2 version) but a name like
'powerpc--openbsd-gcc-e' could be better, then you could go with the same kind of names
using 'powerpc--openbsd-g++-e', 'gcov-e', 'c++filt-e' and '*protoize-e'. This is the
naming I use for egcs-versions (and adding '-o' to the names of older gcc-2.8.x or
gcc-2.7.x versions).

 For some targets egcs-1.1.2 produces smaller code (perhaps slower) than gcc-2.95.2,
so the smaller kernel size (e.g. 800k, not 1000k) may be an issue. This may happen
with the default options, but with '-Os' they may produce just the same code. With
the defaults it seems like gcc-2.95.2 would produce a little bigger code (perhaps it
aligns everything to start at 32-bit boundaries).

 Building the 'official' GCC/egcs version as the reference compiler, not trusting
to only the one you have now, would be my suggestion, at least in this case where
your first compiler (gcc-2.95.2) doesn't seem to be yet 'officially' supported. It
may work ok --- all generic PowerPC-stuff should of course work, but there may be
some things in the OpenBSD kernel sources which are dependent on some 'features'
in the earlier GCC versions. The Linux 2.0.x kernels had problems with egcs and
they must be compiled with gcc-2.7.2.x...

Cheers, Kai


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com