This is the mail archive of the crossgcc@sourceware.cygnus.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more infromation.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |