embedded gcc linker issue--trying to build for m68000 cpu
in [Embedded]
|
From: Jim on 2 Nov 2009 19:24 Hi, I'm using the free Code Sourcery Lite gcc for m68k for a home project that involves a micro with 68000 cpu core. I added -lgcc to the linker flags to resolve an issue with __divsi3. However, now I get the following linker error: c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/m68k- elf/4.2.1/../../../../m68k-elf/bin/ld.exe: m68k:isa-a:nodiv architecture of input file `c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/m68k-elf/4.2.1\libgcc.a(_divsi3.o)' is incompatible with m68k:68000 output My ccompiler flags are: CFLAGS =-m68000 $(INCLUDES) CFLAGS += -fno-exceptions CFLAGS += -Wall -Wa,-m68000 CFLAGS += -ggdb My linker flags are: LFLAGS = $(CFLAGS) -Wl,-Map,$(basename $@).map,--cref LFLAGS += -nostdlib LFLAGS += -nostartfiles LFLAGS += -nodefaultlibs LFLAGS += -lgcc CodeSourcery is "for" Coldfire which (I think) has a richer instruction set than the 68000 cpu I have. If this is true and that lib is built with that instruction set, it wouldn't be compatible with my object code. I think this is what the error is saying. I have an old Linux box with v2.2 Linux on it, so I COULD build my own cross compiler for WinXP, or I could try the cygwin deal and build it on WinXP, but let's face it, either would be a real pain. Does anyone have any better ideas? Thanks much, Jim
From: DJ Delorie on 2 Nov 2009 23:33 You can get the sources for libgcc and rebuild it with the target-specific options you need, giving you an optimized (and appropriate) libgcc.a. You already have the right compiler for it :-)
From: Didi on 3 Nov 2009 00:50 On Nov 3, 2:24 am, Jim <adirondack...(a)yahoo.com> wrote: > .... > CodeSourcery is "for" Coldfire which (I think) has a richer > instruction set than the 68000 cpu I have. > Don't know your compiler etc. stuff, but 68k and coldfire are not that compatible - either way, each has opcodes the other one does not support. Coldfire uses only a subset of the 68000 opcodes, and I am pretty sure I have seen different coldfires which have some own new ones the 68000 did not use. Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/ Original message: http://groups.google.com/group/comp.arch.embedded/msg/027d2e7140029a37?dmode=source
From: David Brown on 3 Nov 2009 10:00 Jim wrote: > Hi, > > I'm using the free Code Sourcery Lite gcc for m68k for a home project > that involves a micro with 68000 cpu core. I added -lgcc to the Which cpu? Code Sourcery gcc supports a large number of m68k family devices - there may be a closer match than -m68000. Are you calling the linker using "m68k-elf-ld" or "m68k-elf-gcc"? Normally, you want to use "gcc" rather than calling "ld" directly. You should not need "-lgcc". Using "gcc" as the driver for the linker, it should be able to figure out which basic libraries are needed, and match them up for your cpu. Have you read the "getting started" guide that comes with Code Sourcery downloads? > linker flags to resolve an issue with __divsi3. However, now I get > the following linker error: > > c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/m68k- > elf/4.2.1/../../../../m68k-elf/bin/ld.exe: m68k:isa-a:nodiv > architecture of input file `c:/program files/codesourcery/sourcery g++ > lite/bin/../lib/gcc/m68k-elf/4.2.1\libgcc.a(_divsi3.o)' is > incompatible with m68k:68000 output > The latest version is now at gcc 4.4, if you want to keep up to date. That won't make any difference to your current issue, of course. > My ccompiler flags are: > CFLAGS =-m68000 $(INCLUDES) > CFLAGS += -fno-exceptions > CFLAGS += -Wall -Wa,-m68000 > CFLAGS += -ggdb > > My linker flags are: > LFLAGS = $(CFLAGS) -Wl,-Map,$(basename $@).map,--cref > LFLAGS += -nostdlib > LFLAGS += -nostartfiles > LFLAGS += -nodefaultlibs > LFLAGS += -lgcc > What are your full command lines? > > CodeSourcery is "for" Coldfire which (I think) has a richer > instruction set than the 68000 cpu I have. If this is true and that > lib is built with that instruction set, it wouldn't be compatible with > my object code. I think this is what the error is saying. I have an CodeSourcery maintain and support gcc for a number of targets. The "ColdFire" and "m68k" target are the same, since the architecture is fundamentally the same. The port supports a wide range of m68k variants, including (AFAIK) all the current ColdFire cores and almost all 68k cores that were made. Libraries suitable for any of these cores are also included. While it is not impossible that you have a cpu core that is not supported, I think it is unlikely - it is much more likely that you are giving the compiler and the linker conflicting information about the core and the libraries you want. > old Linux box with v2.2 Linux on it, so I COULD build my own cross > compiler for WinXP, or I could try the cygwin deal and build it on > WinXP, but let's face it, either would be a real pain. Does anyone > have any better ideas? > Linux 2.2 is /very/ old. Getting a modern gcc cross-compiler working on such a system will be a challenge - you probably won't be able to compile the current gcc source code with the older compiler and tools you have on the system at the moment, and your distribution is unlikely to have ready-to-run current gcc (plus make, binutils, etc.) binaries. This means you would have to build an intermediary native gcc from sources (all released versions are available from the FSF archives), use that to build a current native toolchain, and then use that to build the cross-compiler. It's fun if you like that sort of thing... If you want to use Linux for development work, I'd advise joining the 21st century - it's a lot easier using a modern system (you can then use the binaries directly from CodeSourcery if you want). For windows gcc builds, you really want to use MinGW/MSys these days - it's much faster (both the build process, and the resultant binaries) than with cygwin, and avoids all the "cygwin1.dll" issues. Of course, this is all fairly academic - building your own cross-compiler is mostly just for those that are interested in that sort of thing, since the pre-build binaries work perfectly well. CodeSourcery also have a mailing list that you can join, and paid support if you want that. mvh., David
From: ChrisQ on 3 Nov 2009 11:01 Jim wrote: > Hi, > > I'm using the free Code Sourcery Lite gcc for m68k for a home project > that involves a micro with 68000 cpu core. I added -lgcc to the > linker flags to resolve an issue with __divsi3. However, now I get > the following linker error: > > c:/program files/codesourcery/sourcery g++ lite/bin/../lib/gcc/m68k- > elf/4.2.1/../../../../m68k-elf/bin/ld.exe: m68k:isa-a:nodiv > architecture of input file `c:/program files/codesourcery/sourcery g++ > lite/bin/../lib/gcc/m68k-elf/4.2.1\libgcc.a(_divsi3.o)' is > incompatible with m68k:68000 output > > My ccompiler flags are: > CFLAGS =-m68000 $(INCLUDES) > CFLAGS += -fno-exceptions > CFLAGS += -Wall -Wa,-m68000 > CFLAGS += -ggdb > > My linker flags are: > LFLAGS = $(CFLAGS) -Wl,-Map,$(basename $@).map,--cref > LFLAGS += -nostdlib > LFLAGS += -nostartfiles > LFLAGS += -nodefaultlibs > LFLAGS += -lgcc > > > CodeSourcery is "for" Coldfire which (I think) has a richer > instruction set than the 68000 cpu I have. If this is true and that > lib is built with that instruction set, it wouldn't be compatible with > my object code. I think this is what the error is saying. I have an > old Linux box with v2.2 Linux on it, so I COULD build my own cross > compiler for WinXP, or I could try the cygwin deal and build it on > WinXP, but let's face it, either would be a real pain. Does anyone > have any better ideas? > > Thanks much, > > > Jim Don't know if this will be relevant, but here some lines from a makefile from around 1992, using gcc2.7.2 cross to dragonball 68000: ROOT = /usr/local/aerosys/sw-lib SYSINC = $(ROOT)/sys-include SYSLIB = $(ROOT)/sys-lib SRCDIR = $(ROOT)/bsp/cms-qf200/src INCDIR = $(ROOT)/bsp/cms-qf200/inc OBJDIR = $(ROOT)/bsp/cms-qf200/obj LSTDIR = $(ROOT)/bsp/cms-qf200/lst LIBDIR = $(ROOT)/bsp/cms-qf200/lib SCRIPTDIR = $(ROOT)/bsp/cms-qf200/script CC68ROOT = /usr/local/gcc-68k CC68LIB = $(CC68ROOT)/m68k-coff/lib/m68000 CC68LIBS = libc.a libm.a LIBGCC = $(CC68ROOT)/lib/gcc-lib/m68k-coff/2.7.2.3/m68000/libgcc.a and # CC = cc68k CFLAGS = -O2 -m68000 -ansi -Wall -fomit-frame-pointer -fvolatile -nostdinc -I- CC68INC = /usr/local/gcc-68k/m68k-coff/include AS = as68k ASFLAGS = -m68000 AR = ar68k ARFLAGS = crvs LD = ld68k LDSCRIPT = -T$(SCRIPTDIR)/bsp.ld LDFLAGS = $(LDSCRIPT) -t -cref -Map bsp.map This was originally running under tru64 alpha, but also later on sparc sol10. Gcc 2.7.2 is fairly old, but was quite mature at that point, produces reasonable code and was able to build the toolchain without too much trouble on what was and is an unsupported platform... Regards, Chris
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: LPC2888 Flash programming using DFU. Next: servo motor controller using dspic |