embedded gcc linker issue--trying to build for m68000 cpu
Jim
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
DJ Delorie
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 :-)
Didi
> ....
> 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.flickr.com/photos/didi_tgi/sets/72157600228621276/
Original message: http://groups.google.com/group/comp.arch.embedded/msg/027d2e7140029a37?dmode=source
David Brown
> 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
ChrisQ
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
ChrisQ
> from around 1992, using gcc2.7.2 cross to dragonball 68000:
^^^^
Correction, should be 2002...
Regards,
Chris
42Bastian Schick
<da...@westcontrol.removethisbit.com> 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 bast...@yahoo.com, it's a spam-only account :-)
Use <same-name>@monlynx.de instead !
ChrisQ
> 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
Chris Burrows
news:342fac09-113a-4a00...@p8g2000yqb.googlegroups.com...
>
> 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
David Brown
> On Tue, 03 Nov 2009 16:00:30 +0100, David Brown
> <da...@westcontrol.removethisbit.com> 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.
Hans-Bernhard Bröker
> 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.
That should never be necessary. GCC already puts -lgcc into the linker
command line it builds, whenever that serves a useful purpose.
> 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.
More to the point, GCC would probably have to be built with multilib
support to allow switching between incompatible variants of the same
basic CPU architecture. That would include multiple copies of libraries
such as libgcc, the Standard C++ runtime, and startup code as needed,
and the gcc driver program would automatically pick those needed for the
chosen architecture.
For whatever reasons, your GCC apparently wasn't built that way. Maybe
you need to pick a different package. Or, who knows, you may even have
to bite the bullet and build your own GCC tool chain.
David Brown
CodeSourcery gcc (for the ColdFire, anyway - I don't know about other
targets) /is/ built with multilib. It's just that they don't supply
pre-built libraries for all the architectures supported by the compiler
- pure 68000 is so old that it's rarely used. Mind you, other devices
such as the 68332 are still very much in use, and there are no pre-built
libraries for the CPU32 core either - the downloadable binaries (in the
"lite" version anyway) only include ColdFire libraries.
Jim
to answer some of the questions so no one feels left out:
- The target cpu is truly a 68000 core (the old Dragonball EZ328).
Now, to avoid the "why": it's a Palm pda which has a display and
formfactor that I need and it's cheap.
- I'm using my own OS on the embedded system (no Linux).
- Now that I think about it, I upgraded my Linux box to 2.4, so I'm
not that "ancient" :). I have a 2.6 one at work. I want to do my
development work in MS Windows, but I could build libgcc on Linux, if
I have to).
- I read the GettingStarted guide and I looked at all the libgcc.a
files: all seem to be ColdFire based :(.
- I'm coding mostly from scratch. However, I'm using a modified GDB
stub from David Williams.
- The only two languages I'll consider using for embedded projects are
C and C++ (plus the little bit of necessary assembly). It's what I'm
really familiar with.
- I don't really care if the object code is COFF or ELF. The
executable has to be straight binary though.
- I use gcc for linking. But I still need to explicitly say -lgcc
because of the -nodefaultlibs linker flag (I think). For the sake of
completeness, my compile and link lines are:
m68k-elf-gcc -o bin/main.o -m68000 -I. -I../shared -fno-exceptions -
Wall -Wa,-m68000 -ggdb -c main.c
m68k-elf-gcc -Wl,-T,RadioTest.ldi bin/MyStartup.o bin/main.o bin/
Timer.o -o bin/RadioTest.elf -m68000 -I. -I../shared -fno-exceptions -
Wall -Wa,-m68000 -ggdb -Wl,-Map,bin/RadioTest.map,--cref -nostdlib -
nostartfiles -nodefaultlibs -lgcc
So, I think the general consensus is I only get ColdFire micro support
with CodeSourcery and I agree with this. I can understand why
CodeSourcery may want to ignore older cores. However, don't they
still make micros with that (68000 based) core? I might email them,
but since I'm using the free version, I feel funny bothering them with
this (they do need to earn a living). Purchasing it would be a real
gamble since they do say it's a ColdFire compiler on their website
(and for home use, it's kinda a pricey gamble).
I'm gonna try two things. First, I'll look for other precompiled
binaries for MS Windows. Maybe I'll luck out. I came across one the
other day, but now can't remember for the life of me who made it--I'm
sure it'll turn up in a search.
Second, I'll see if I can build libgcc. I assume I'll get the source
to this when I download the source to gcc. David suggested I use
MinGW. I'm pretty sure I'll need "configure" and maybe autoconf &
automake. I'm not familiar with MinGW: does that package have them?
I just got an idea. PrcTools was a MS Windows compiler for that very
micro. I remember trying it, but it was a limited 16b compiler trying
to be compatible with the Palm OS. However, I might be able to use
its libgcc. The only issue is that compiler is so old it's probably
COFF based (and of course CodeSourcery is ELF). Nothing's ever
easy. :)
Well, thanks again for your help everyone. I'll post what I finally
end up with (in case anyone else needs the info).
Jim
42Bastian Schick
wrote:
>First, I'd like to thank everyone for their input! Second, I'd like
>to answer some of the questions so no one feels left out:
>
>- The target cpu is truly a 68000 core (the old Dragonball EZ328).
>Now, to avoid the "why": it's a Palm pda which has a display and
>formfactor that I need and it's cheap.
Funny, have such lying around and waiting for a project :-)
>Second, I'll see if I can build libgcc. I assume I'll get the source
>to this when I download the source to gcc.
Why not just add the needed functions to your project ?
I mean, LD will complain about missing __???? and you just pull the
source and that's it.
I wouldn't bother building libgcc.a
>Well, thanks again for your help everyone. I'll post what I finally
>end up with (in case anyone else needs the info).
Yes, please do so.
Tauno Voipio
> On Wed, 4 Nov 2009 15:58:50 -0800 (PST), Jim <adiron...@yahoo.com>
> wrote:
>
>> First, I'd like to thank everyone for their input! Second, I'd like
>> to answer some of the questions so no one feels left out:
>>
>> - The target cpu is truly a 68000 core (the old Dragonball EZ328).
>> Now, to avoid the "why": it's a Palm pda which has a display and
>> formfactor that I need and it's cheap.
>
> Funny, have such lying around and waiting for a project :-)
>
>> Second, I'll see if I can build libgcc. I assume I'll get the source
>> to this when I download the source to gcc.
>
> Why not just add the needed functions to your project ?
> I mean, LD will complain about missing __???? and you just pull the
> source and that's it.
> I wouldn't bother building libgcc.a
>
>> Well, thanks again for your help everyone. I'll post what I finally
>> end up with (in case anyone else needs the info).
>
> Yes, please do so.
>
The compiler will generate the libgcc.a calls when it
feels them needed. There's little that the programmer
can control here.
Contrary to the C library, libgcc.a is needed nearly
always when GCC generates code. You cannot skip it.
(Been there, done that - GCC ports to ARM/Thumb at GCC 2.95 time)
--
Tauno Voipio
Chris Burrows
> - The target cpu is truly a 68000 core (the old Dragonball EZ328).
> - I'm using my own OS on the embedded system (no Linux).
> I want to do my
> development work in MS Windows
> - I'm coding mostly from scratch.
> - The only two languages I'll consider using for embedded projects are
> C and C++ (plus the little bit of necessary assembly). It's what I'm
> really familiar with.
> - I don't really care if the object code is COFF or ELF. The
> executable has to be straight binary though.
> First, I'll look for other precompiled
> binaries for MS Windows.
>
If you hit a brick wall with gcc check out the Manx Aztec C68K MS-DOS
cross-compiler. AFAIR Aztec C had a great reputation in the 1980's.
The software rebundled for Windows XP is here:
http://www.aztecmuseum.ca/compilers.htm#aztec68K
The manual is here:
http://www.bitsavers.org/pdf/manx/
--
Chris Burrows
CFB Software
ChrisQ
> First, I'd like to thank everyone for their input! Second, I'd like
> to answer some of the questions so no one feels left out:
>
> - The target cpu is truly a 68000 core (the old Dragonball EZ328).
> Now, to avoid the "why": it's a Palm pda which has a display and
> formfactor that I need and it's cheap.
If you are working with dragonball, there were loads of sites out there
a few years ago and some are most likely still around, Mark Wyman's site
was one, another called dragonball developers lair and there were
others. I only stopped using 328 series because it went eol at motorola.
Was not pleased and needless to say, I won't be using their product in
the future :-(.
I used the vz328 and built the tool chain from source, originally gcc
2.7.2. It wasn't the latest version, but found it more than up to the
task. It was rebuilt for solaris 10 on sparc a year or two ago with
version gcc 2.95.1, binutils 2.1 and newlib-1.8.2. 2.95 produces pretty
good code and seems bug free, so there's no real point in upgrading to a
later version, which seems to get more difficult to build from source
with every revision.
If you need sol10 sparc binaries for the toolchain, let me know...
Regards,
Chris
David Brown
> First, I'd like to thank everyone for their input! Second, I'd like
> to answer some of the questions so no one feels left out:
>
> - The target cpu is truly a 68000 core (the old Dragonball EZ328).
> Now, to avoid the "why": it's a Palm pda which has a display and
> formfactor that I need and it's cheap.
> - I'm using my own OS on the embedded system (no Linux).
> - Now that I think about it, I upgraded my Linux box to 2.4, so I'm
> not that "ancient" :). I have a 2.6 one at work. I want to do my
> development work in MS Windows, but I could build libgcc on Linux, if
> I have to).
These days, gcc and related tools can all be built happily on windows
with mingw and msys. Building on Linux can be much faster and easier,
especially if you want to do the optional parts like building the man
pages or using the autoconf stuff, but for the compiler and libraries
there should be no real problem - if you still want to do that. The
source download from CodeSourcery should give you what you need, in
addition to mingw and msys. You may need to get a few of the extra
mingw/msys packages.
> - I read the GettingStarted guide and I looked at all the libgcc.a
> files: all seem to be ColdFire based :(.
Yes, it looks very much like that's the only libraries they have
pre-built. But the compiler certainly supports it the 68000 devices.
An alternative idea is just to find some older binaries from around the
net. CodeSourcery always has the latest versions with the newest
features, since they are the maintainers, but there are plenty of other
builds around. Development tool resellers and debugger vendors often
have packages to download - try some and see if you get the right
libraries there, saving you some effort. For example,
<http://www.macraigor.com/full_gnu.htm>
> - I'm coding mostly from scratch. However, I'm using a modified GDB
> stub from David Williams.
> - The only two languages I'll consider using for embedded projects are
> C and C++ (plus the little bit of necessary assembly). It's what I'm
> really familiar with.
> - I don't really care if the object code is COFF or ELF. The
> executable has to be straight binary though.
> - I use gcc for linking. But I still need to explicitly say -lgcc
> because of the -nodefaultlibs linker flag (I think). For the sake of
> completeness, my compile and link lines are:
>
> m68k-elf-gcc -o bin/main.o -m68000 -I. -I../shared -fno-exceptions -
> Wall -Wa,-m68000 -ggdb -c main.c
>
> m68k-elf-gcc -Wl,-T,RadioTest.ldi bin/MyStartup.o bin/main.o bin/
> Timer.o -o bin/RadioTest.elf -m68000 -I. -I../shared -fno-exceptions -
> Wall -Wa,-m68000 -ggdb -Wl,-Map,bin/RadioTest.map,--cref -nostdlib -
> nostartfiles -nodefaultlibs -lgcc
>
>
> So, I think the general consensus is I only get ColdFire micro support
> with CodeSourcery and I agree with this. I can understand why
> CodeSourcery may want to ignore older cores. However, don't they
> still make micros with that (68000 based) core? I might email them,
> but since I'm using the free version, I feel funny bothering them with
> this (they do need to earn a living). Purchasing it would be a real
> gamble since they do say it's a ColdFire compiler on their website
> (and for home use, it's kinda a pricey gamble).
>
The support for the free version is a mailing list. You don't get any
guarantees of an answer, and it might be from another user rather than a
CodeSourcery developer, but my experience is that they are helpful
regardless of whether or not the poster is a customer. You should feel
entirely free to post to these lists. They will also be able to tell
you whether the commercial versions of their tools have the right
pre-built libraries (you can also download a 30-day trial version of
those tools).
Another mailing list of possible interest is cold...@wildrice.com.
> I'm gonna try two things. First, I'll look for other precompiled
> binaries for MS Windows. Maybe I'll luck out. I came across one the
> other day, but now can't remember for the life of me who made it--I'm
> sure it'll turn up in a search.
>
> Second, I'll see if I can build libgcc. I assume I'll get the source
> to this when I download the source to gcc. David suggested I use
> MinGW. I'm pretty sure I'll need "configure" and maybe autoconf &
> automake. I'm not familiar with MinGW: does that package have them?
>
I can't remember off-hand if you get autoconf and automake with the
standard mingw/msys packages - it's a while since I installed a new
version of these tools, and the packaging has changed a little since
then. But you can certainly find out about them on the mingw and msys
websites.
> I just got an idea. PrcTools was a MS Windows compiler for that very
> micro. I remember trying it, but it was a limited 16b compiler trying
> to be compatible with the Palm OS. However, I might be able to use
> its libgcc. The only issue is that compiler is so old it's probably
> COFF based (and of course CodeSourcery is ELF). Nothing's ever
> easy. :)
>
You probably don't want to mix libgcc from a different version than the
gcc compiler. libgcc is a support library for the compiler, and is
closely tied to it - it's not like the standard C library that can be
replaced.
Jim
> First, I'd like to thank everyone for their input! Second, I'd like
> to answer some of the questions so no one feels left out:
>
> - The target cpu is truly a 68000 core (the old Dragonball EZ328).
> Now, to avoid the "why": it's a Palm pda which has a display and
> formfactor that I need and it's cheap.
> - I'm using my own OS on the embedded system (no Linux).
>
>
> So, I think the general consensus is I only get ColdFire micro support
> with CodeSourcery and I agree with this. I can understand why
> CodeSourcery may want to ignore older cores. However, don't they
> still make micros with that (68000 based) core? I might email them,
> but since I'm using the free version, I feel funny bothering them with
> this (they do need to earn a living). Purchasing it would be a real
> gamble since they do say it's a ColdFire compiler on their website
> (and for home use, it's kinda a pricey gamble).
>
> I'm gonna try two things. First, I'll look for other precompiled
> binaries for MS Windows. Maybe I'll luck out. I came across one the
> other day, but now can't remember for the life of me who made it--I'm
> sure it'll turn up in a search.
>
> to this when I download the source to gcc. David suggested I use
> MinGW. I'm pretty sure I'll need "configure" and maybe autoconf &
> automake. I'm not familiar with MinGW: does that package have them?
>
> I just got an idea. PrcTools was a MS Windows compiler for that very
> micro. I remember trying it, but it was a limited 16b compiler trying
> to be compatible with the Palm OS. However, I might be able to use
> COFF based (and of course CodeSourcery is ELF). Nothing's ever
> easy. :)
>
> Well, thanks again for your help everyone. I'll post what I finally
> end up with (in case anyone else needs the info).
>
> Jim
Problem solved. I looked at the libc files and they were pretty
simple. I think there was only one macro definition I had to figure
out. But, then I realized my next step would be to build newlib and
that wasn't gonna be that simple.
I looked at a bunch of pre-built stuff (thanks again everyone for the
links--I may compare the Aztec C output to gcc someday). I decided I
really wanted GNU because I know the debugger works with Eclipse.
By the way, the other pre-built gcc I was thinking of was www.ronetix.it.
It had everything I needed, but, unfortunately, there was a flaw with
it (either the binary wasn't produced correctly or gdb didn't load it
correctly--I didn't look into it further). One other by ASH WARE was
too old (2.95 and coff based--I wasn't sure an elf type gdb would
handle it). The Macgregor (sp?) didn't run (I need a cygwin dll).
So, I ended up building gcc and newlib using mingw/msys like David
suggested. I was intrigued by the idea. I'm still gonna use
CodeSourcery's gcc though (I figure they ran some of the gcc tests).
I'll just link to the libc, libgcc, etc. produced by me (so far tests
show it's ok). It wasn't TOO bad building the libs. There were some
tricks to get things to build right--I spent some time doing
searches. I think the biggest thing to remember is that many tools
want you to do these three things:
(1) create a folder outside of the source tree to hold intermediate
files.
(2) run configure and build from the folder created in (1)
(3) Use a RELATIVE path when running configure in (2). You can get
weird compile errors otherwise. Unfortunately many docs have scripts
that use the full path (including the one at mingw). Maybe this used
to work for older gcc.
One last thing: gcc needs to build mpfr and gmp. It turns out for
the 4.2.1 and 4.4.2 releases I did, all you have to do it place the
source in the gcc folder (omit the -version part of the folder name).
I'm sure there's other ways to do it as well.
Well, thanks again everyone for all of your input! It was fun (for me
anyways)!!
Jim
42Bastian Schick
<adiron...@yahoo.com> wrote:
>Well, thanks again everyone for all of your input! It was fun (for me
>anyways)!!
Thanks for follow-up Jim.
David Brown
Installing cygwin isn't hard, unless you bump into problems with
incompatible versions of cygwin1.dll...
> So, I ended up building gcc and newlib using mingw/msys like David
> suggested. I was intrigued by the idea. I'm still gonna use
Well done! Building gcc is not as hard as it used to be, but it is
still not for the faint of heart. It is somewhat like fixing your own
car instead of taking it to the garage - it takes time, and you can get
pretty stressed and dirty in the process, but it's fun if you like that
sort of thing and you get a sense of achievement in the end.
> CodeSourcery's gcc though (I figure they ran some of the gcc tests).
> I'll just link to the libc, libgcc, etc. produced by me (so far tests
> show it's ok). It wasn't TOO bad building the libs. There were some
> tricks to get things to build right--I spent some time doing
> searches. I think the biggest thing to remember is that many tools
> want you to do these three things:
> (1) create a folder outside of the source tree to hold intermediate
> files.
> (2) run configure and build from the folder created in (1)
> (3) Use a RELATIVE path when running configure in (2). You can get
> weird compile errors otherwise. Unfortunately many docs have scripts
> that use the full path (including the one at mingw). Maybe this used
> to work for older gcc.
>
Good advice.
> One last thing: gcc needs to build mpfr and gmp. It turns out for
> the 4.2.1 and 4.4.2 releases I did, all you have to do it place the
> source in the gcc folder (omit the -version part of the folder name).
> I'm sure there's other ways to do it as well.
>
> Well, thanks again everyone for all of your input! It was fun (for me
> anyways)!!
>
Thanks for the feedback.