This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
On Thu, 12 Jul 2001 13:13:26 +0800 "Liu Yong" <yliu@newavetech.com> wrote: > I think I haven't made things clear. > I have succeeded in building core-gcc as you described > in your mail. > And succeeded building newlib. I would disagree ;-) > But failed to build cross-gcc,the last step. > configure: error: installation or configuration problem: C compiler > cannot create executables. This is somehow misleading, the linking phase fails, not the compiler. Using '--with-newlib' in configure should have worked around the sanity check in libiberty-configure (where this error comes). Newlib is a known thing so scanning the 'libc.a' in it can be left undone. Before one can create executables for the real target, one must have a working toolset with a proper linker script, startup, libs and sane instructions for the link-phase in the 'specs'-file... > I have looked at the directory /home/yliu/local/m68k-hp-bsd4.3/bin/ , > /home/yliu/local/m68k-hp-bsd4.3/lib/ and > /home/yliu/local/m68k-hp-bsd4.3/include ,there are files in there: > bin: ar as c++ g++ gcc ld nm ranlib strip > lib: bcc.ld crt0.o idp.ld libgcc.a libdbug.a libidp.a libmvme135.a > libmvme162.a libnosys.a mvme135.ld mvme162.ld sbc5204.ld sbc5206.ld The C-library ('libc.a') and the C-math library ('libm.a') are missing. Building and installing newlib should have produced them and they should be in the 'lib'-subdir... Also subdirs like 'm68000', 'm5200', 'm68040', 'm68060', 'mcpu32', 'msoft-float' etc. should exist for the CPU/FPU-variations. Your current 'just some m68k-target' / 'm68k-hp-bsd4.3' doesn't produce anything else than the '-m68020 -m68881' variation libraries... I would suggest using some more common 'generic' target like 'm68k-aout', 'm68k-coff' or 'm68k-elf' for the toolset. And to think about which ones in the m68k-family should be supported... The BSVC-simulator supports m68000 and cpu32 (m68360), so if this sim looks promising, the m68000 and mcpu32 support libs should be produced. The 'gcc/config/m68k/t-m68kbare' controls the produced 'multilibs', changing the MULTILIB* definitions there sets the compiler to support just the CPUs you will want it to support... Or to use a BSVC-specific target 'm68k-bsvc2.1' as described later... > include: there is no include directory ,just a sys-include directory that > contains a file named COPIED (file length is 3 bytes, just has a > word 'no') Copying the newlib headers into the 'include' shouldn't be a problem, just use something like: cp -r -p -v newlib-1.9.0/newlib/libc/include /home/yliu/local/m68k-hp-bsd4.3 now and rename the 'm68k-hp-bsd4.3' into something else ('m68k-coff',...) if you change the $target but keep the $prefix... The 'sys-include' can be used as the place for the '3rd-party' headers from Motorola etc. for the chips and their I/O-addresses and specific bit names... BTW, I finally decided to make a specific target toolset, 'm68k-bsvc2.1', for the BSVC 2.1 simulators. So I added this new target to gcc-2.95.3, it being an alias to the 'm68k-aout', then did the same for newlib-1.9.0 and built the toolset. Must make an Insight/GDB for this toolset too... Of course I could have decided to use my existing 'm68k-coff' and 'm68k-elf' toolsets with BSVC, but when missing a 'm68k-aout' from my collection, this was a good enough reason to add it... The next phase could be to build glue libraries, 'libbsvc.a's, for the 'BSVC' m68000 and m68360 'boards'... Adding the 'm68k-bsvc*' target into gcc-2.95.3 happens as follows: 1. Edit the main 'config.sub' by adding a ' | -bsvc*' somewhere where the script checks for the known 'systems', like : --------------------- clip ----------------------------------------------- *** config.bak Mon Jun 18 18:44:14 2001 --- config.sub Tue Jul 10 19:59:56 2001 *************** *** 940,946 **** | -*vms* | -sco* | -esix* | -isc* | -aix* | -sunos | -sunos[34]*\ | -hpux* | -unos* | -osf* | -luna* | -dgux* | -solaris* | -sym* \ | -amigaos* | -amigados* | -msdos* | -newsos* | -unicos* | -aof* \ ! | -aos* | -djgpp2* \ | -nindy* | -vxsim* | -vxworks* | -ebmon* | -hms* | -mvs* \ | -clix* | -riscos* | -uniplus* | -iris* | -rtu* | -xenix* \ | -hiux* | -386bsd* | -netbsd* | -openbsd* | -freebsd* | -riscix* \ --- 940,946 ---- | -*vms* | -sco* | -esix* | -isc* | -aix* | -sunos | -sunos[34]*\ | -hpux* | -unos* | -osf* | -luna* | -dgux* | -solaris* | -sym* \ | -amigaos* | -amigados* | -msdos* | -newsos* | -unicos* | -aof* \ ! | -aos* | -djgpp2* | -bsvc* \ | -nindy* | -vxsim* | -vxworks* | -ebmon* | -hms* | -mvs* \ | -clix* | -riscos* | -uniplus* | -iris* | -rtu* | -xenix* \ | -hiux* | -386bsd* | -netbsd* | -openbsd* | -freebsd* | -riscix* \ --------------------- clip ----------------------------------------------- 2. Add the '| m68k-*-bsvc*' into the 'm68k-*-aout*' config-entry in 'gcc/configure' : --------------------- clip ----------------------------------------------- *** configure.bak Tue Jul 3 15:31:22 2001 --- configure Tue Jul 10 19:47:51 2001 *************** *** 4413,4427 **** extra_headers=math-68881.h ;; m68k-wrs-vxworks*) - tm_file=m68k/vxm68k.h tmake_file=m68k/t-vxworks68 extra_headers=math-68881.h - thread_file='vxworks' float_format=m68k ;; ! m68k-*-aout*) tmake_file=m68k/t-m68kbare ! tm_file="m68k/m68k-aout.h libgloss.h" extra_headers=math-68881.h float_format=m68k ;; --- 4413,4427 ---- extra_headers=math-68881.h ;; m68k-wrs-vxworks*) tmake_file=m68k/t-vxworks68 + tm_file=m68k/vxm68k.h extra_headers=math-68881.h float_format=m68k + thread_file='vxworks' ;; ! m68k-*-aout* | m68k-*-bsvc*) tmake_file=m68k/t-m68kbare ! tm_file="m68k/m68k-aout.h" extra_headers=math-68881.h float_format=m68k ;; --------------------- clip ----------------------------------------------- The stuff order in the 'm68k-wrs-vxworks*' was also rearranged for my artistic eyes... Editing the 'config.sub' in 'newlib-1.9.0' sources quite in the same way can be left as an homework... No other changes to newlib needed. Perhaps a totally 'new' target for GCC could have been added, like: m68k-*-bsvc*) tmake_file=m68k/t-m68kbsvc tm_file="m68k/m68k-aout.h" extra_headers=math-68881.h float_format=m68k ;; and the 't-m68kbsvc' (using 't-m68kbare' as the template) edited to produce only the extra 'm68000' support with this target, the 'mcpu32' being the default option (not the 'm68020' and 'm68881' as in the plain vanilla GCC-sources)... The 'm68332' or 'mcpu32' can be set as the default CPU-type in 'gcc/config/m68k/m68k-none.h' and I think the things to do this were handled on this list earlier, but a quick reminder here would be to edit the : #ifndef TARGET_CPU_DEFAULT #define TARGET_CPU_DEFAULT M68K_CPU_m68332 #endif in the beginning of 'm68k-none.h' to be as shown... 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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |