Re: problems cross-compilng gcc

[Andy <andy at softbook dot com>]

Well there's a glimmer of hope..
I realized that running i386 nm on a powerpc .o file is kinda silly..
so ran it thru powerpc--openbsd-nm  on a  libkern.o  file and got this:

0000011c T __divdi3
00000050 T __moddi3
000001e8 T __qdivrem
0000002c T __udivdi3
00000000 T __umoddi3
00000000 g zero.3

no wonder it complains that bcmp and bzero are undefined..

Where the heck are other symbols ( about a  dozen of them) ??
Is it the problem with the compiler or the Makefile?
I guess I'll find out:-))

Andy



>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