Motherboard Forums


Reply
Thread Tools Display Modes

embedded gcc linker issue--trying to build for m68000 cpu

 
 





















Jim
Guest
Posts: n/a

 
      11-03-2009, 12:24 AM


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
 
Reply With Quote
 
DJ Delorie
Guest
Posts: n/a

 
      11-03-2009, 04:33 AM

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 :-)
 
Reply With Quote
 
Didi
Guest
Posts: n/a

 
      11-03-2009, 05:50 AM
On Nov 3, 2:24*am, Jim <adirondack...@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_tg...7600228621276/

Original message: http://groups.google.com/group/comp....7?dmode=source
 
Reply With Quote
 
David Brown
Guest
Posts: n/a

 
      11-03-2009, 03:00 PM
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
 
Reply With Quote
 
ChrisQ
Guest
Posts: n/a

 
      11-03-2009, 04:01 PM
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



 
Reply With Quote
 
ChrisQ
Guest
Posts: n/a

 
      11-03-2009, 04:05 PM
ChrisQ wrote:


> from around 1992, using gcc2.7.2 cross to dragonball 68000:

^^^^

Correction, should be 2002...

Regards,

Chris
 
Reply With Quote
 
42Bastian Schick
Guest
Posts: n/a

 
      11-03-2009, 07:53 PM
On Tue, 03 Nov 2009 16:00:30 +0100, David Brown
<> wrote:

>Which cpu? Code Sourcery gcc supports a large number of m68k family
>devices - there may be a closer match than -m68000.


It looks to me like a bug, a simple

x.c:
int main() { return 0; }

m68k-elf-gcc -o x.elf -m68000 x.c

gives also below 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


Jim, maybe you really need to check if 68000 is still supported by
newer gcc ?

--
42Bastian
Do not email to , it's a spam-only account :-)
Use <same-name>@monlynx.de instead !
 
Reply With Quote
 
ChrisQ
Guest
Posts: n/a

 
      11-03-2009, 09:52 PM
Jim wrote:

> lite/bin/../lib/gcc/m68k-elf/4.2.1\libgcc.a(_divsi3.o)' is
> incompatible with m68k:68000 output



Looking at that again, it looks like the libgcc.a, which is processor
specific and required by the compiler, iirc, to resolve some
instructions, is being pulled in from the wrong place.

On my makefile:

LIBGCC = $(CC68ROOT)/lib/gcc-lib/m68k-coff/2.7.2.3/m68000/libgcc.a

libgcc.a comes from a separate cpu specific directory. Have a look to
see if there is any similar directory structure for 4.2.1...

Regards,

Chris
 
Reply With Quote
 
Chris Burrows
Guest
Posts: n/a

 
      11-03-2009, 10:41 PM
"Jim" <> wrote in message
news:342fac09-113a-4a00-8576-...
>
> I'm using the free Code Sourcery Lite gcc for m68k for a home project
> that involves a micro with 68000 cpu core.

....
....
>
> 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?
>


Thinking outside the square ...

The 680x0 development tools I use include a cross-assembler running on DOS /
Windows, a Modula-2 compiler on MacOS, the Digital Research C compiler
running on CPM/68K and two Pascal compilers targeting Palm PDAs. I may be
able to advise better knowing more about your requirements:

Does your target system have an OS? If so what is it?

Is C an absolute requirement for the programming language?

Are you writing code from scratch, adapting existing code or hoping to just
recompile existing code?

What is the preferred format of the resulting object files / executables?

--
Chris Burrows
CFB Software
Armaide: ARM Oberon-07 Development System
http://www.armaide.com










 
Reply With Quote
 
David Brown
Guest
Posts: n/a

 
      11-04-2009, 08:13 AM
42Bastian Schick wrote:
> On Tue, 03 Nov 2009 16:00:30 +0100, David Brown
> <> wrote:
>
>> Which cpu? Code Sourcery gcc supports a large number of m68k family
>> devices - there may be a closer match than -m68000.

>
> It looks to me like a bug, a simple
>
> x.c:
> int main() { return 0; }
>
> m68k-elf-gcc -o x.elf -m68000 x.c
>
> gives also below 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

>
> Jim, maybe you really need to check if 68000 is still supported by
> newer gcc ?
>


The 68000 certainly is still supported by gcc, and CodeSourcery's builds
of gcc support it fine for the compiler and binutils. However, it looks
like there are no pre-built libraries for the 68000 in their binaries
(at least, in the version I have installed on my machine). Assuming the
OP really is using a 68000 and not a different m68k device (such as a
68020), then I'd recommend asking on the CodeSourcery mailing list.
They'll be able to give more information, such as whether these
libraries are available pre-built in the paid-for versions of the tools,
or for tips on how to build the libraries yourself.
 
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
For Tiger and Leopard users Michelle Steiner Apple 1 09-11-2009 02:02 AM
Security update 2008-2 Michelle Steiner Apple 0 03-19-2008 12:19 AM
Mac Security: QuickTime 7.2 Update Derek Currie Apple 15 07-15-2007 07:39 AM


All times are GMT. The time now is 09:08 AM.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43