Re: problems cross-compilng gcc

[Andy <andy at softbook dot com>]

Day 3
This time the events unfolded as follows:
I configured the gcc environment using --with-libs and --with-headers options.
This forced the configure script to copy the target libs to
/cross-tools/powerpc--openbsd/lib and
create a directory in /cross-tools/powerpc-openbsd called sys-includes
where it copied all the target headers.
Then I ran make  all install.
It fixed the headers ( or so it said)
The errors it produced during build were the same as  before:
1. conflicting types for sys_errlist ( libiberty/strerror.c)
2. unknown fields of the FILE struct and some undefined flags (
libiberty/vsprintf.c)
3.undefined PATH_MAX ( libchill/basicio.c)
4.   libiberty/strsignal.c: coid psignal(signo, message)
- message declared as const in the header.

In addition to that it produced a "parse error" in gcc/include/stdio.h on
the following routine declarations:

/*


int      vasprintf __P((char **, const char *, _BSD_DUMMY_VA_LIST_))
                __attribute__((format (printf, 2, 0)));
int      vsnprintf __P((char *, size_t, const char *, _BSD_DUMMY_VA_LIST_))
                __attribute__((format (printf, 3, 0)));
int      vscanf __P((const char *, _BSD_DUMMY_VA_LIST_))
                __attribute__((format (scanf, 1, 0)));
int      vsscanf __P((const char *, const char *, _BSD_DUMMY_VA_LIST_))
                __attribute__((format (scanf, 2, 0)));*/


aparrently it couldn't find  _BSD_DUMMY_VA_LIST_ ( I couldn't)

I commented these routines out - well it didn't complain.

After that the buid completed successfully
couple of questions that arose during the build process:
-the  target libraries I told it to use to build the cross-compiler were
built with gcc 2.8.1 -- could this be a part of my problem?

-It built several copies of libiberty:
- gcc*/libiberty
- gcc*/powerpc--openbsd/libiberty
-gcc*/powerpc--openbsd/soft-float/libiberty
Why is this done?
BTW the last 2 libiberty libs were the ones that gave me errors
<<<>>>
Now to the real problem:
when I tried to build a kernel with the cross-compiler I was getting
unresolved link errors ( routines like bcmp, bcopy, bzero,etc.)
These routines are compiled into  libkern.o object  so I examined that and
lo! it's all bogus.
i.e, nm reports:
nm: libkern.o: not object file or archive
I did a hex dump - well  there's elf header but no symbol names.
I  ran nm on  several objects that my cross-compiler produced and all with
the same result:
nm reports that it's not an object file or archive.,
So, looks like my cross-compiler produces garbage.
I'm totally stuck
Any ideas ? anyone?
Thx Andy


>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




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