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] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |