When I installed WinARM to a 2nd computer today,
I messed up the %PATH% and got some files compiled
with GCC3.2 and some with GCC4.0.  And I had same
linker error messages as yours.
Could it be you are running 2 versions of compilers
accidentally??

> the -msoft-float option as reason for the problem.

> I think ARM with Hardware-FP needs the -mhard-float


Where could I find or put in those switches?

These are the messages i get

"c:\program
files\yagarto\bin\..\lib\gcc\arm-elf\4.1.1\..\..\..\..\arm-elf\bin\ld.ex 
e:
ERROR: startup/libea_startup_thumb.a(framework.o) uses software FP,
whereas srv1.elf uses hardware FP"

Im using gcc 4.1.1 on the LPC2106 board from olimex.

My makefile is as follows:

"
##########################################################
#
# General makefile for building executable programs and
# libraries for Embedded Artists' QuickStart Boards.
# (C) 2001-2005 Embedded Artists AB
#
##########################################################

# Name of target (executable program or library)
NAME      = srv1

# Link program to RAM or ROM (possible values for LD_RAMROM is RAM or
ROM,
# if not specified = ROM)
LD_RAMROM = ROM

# Name if specific CPU used (used by linker scripts to define correct
memory map)
# Valid CPUs are: LPC2101, LPC2102, LPC2103, LPC2104, LPC2105, LPC2106
#                 LPC2114, LPC2119
#                 LPC2124, LPC2129
#                 LPC2131, LPC2132, LPC2134, LPC2136, LPC2138
#                 LPC2141, LPC2142, LPC2144, LPC2146, LPC2148
#                 LPC2194
#                 LPC2210, LPC2220, LPC2212, LPC2214,
#                 LPC2290, LPC2292, LPC2294
# If you have a new version not specified above, just select one of the
old
# versions with the same memory map.
CPU_VARIANT = LPC2106

# It is possible to override the automatic linker file selection with
the variable below.
# No not use this opion unless you have very specific needs.
#LD_SCRIPT      = build_files/myOwnLinkScript_rom.ld
#LD_SCRIPT_PATH =

# ELF-file contains debug information, or not
# (possible values for DEBUG are 0 or 1)
# Extra debug flags can be specified in DBFLAGS
DEBUG   = 1
#DBFLAGS =

# Optimization setting
# (-Os for small code size, -O2 for speed)
OFLAGS  = -Os

# Extra general flags
# For example, compile for ARM / THUMB interworking (EFLAGS =
-mthumb-interwork)
EFLAGS  =

# Program code run in ARM or THUMB mode
# Can be [ARM | THUMB]
CODE    = THUMB

# List C source files here.
CSRCS   = main.c \
          uart0.c \
          uart1.c \
          jpeg.c \
          camera.c \
          iap.c \
          utils.c

# List assembler source files here
ASRCS   =

# List subdirectories to recursively invoke make in
SUBDIRS = startup

# List additional libraries to link with
LIBS    = startup/libea_startup_thumb.a

# Add include search path for startup files, and other include
directories
INC     = -I./startup

# Select if an executable program or a library shall be created
PROGRAM_MK  = true
#LIBRARY_MK  = true

# Output format on hex file (if making a program); can be [srec | ihex]
HEX_FORMAT  = ihex

# Program to download executable program file into microcontroller's
FLASH
DOWNLOAD    = lpc21isp.exe

# Configurations for download program
# Which com-pot that is used, which download speed and what crystal
frequency on the board.
DL_COMPORT  = com1
DL_BAUDRATE = 115200
DL_CRYSTAL  = 14746

#######################################################################
include build_files/general.mk
#######################################################################
"

Joerg wrote:
> Hi,
>
> after several clean- and re- builds I found
> the -msoft-float option as reason for the problem.
> (maybe some confusion with GNUARM but I don't think so)
> Floating point treatment of newlib (and gcc-lib?)
> still seems to work without this option.
> Still wonder why my own newlib compilation
> didn't came up with this problem....
> I think ARM with Hardware-FP needs the -mhard-float
> to use it then?
> Thanks for your support (so far :-)
>
> Joerg

The default is to use -mhard-float, but this does not mean that
you have to have a hardware FPU. An FPU instruction without an FPU
present causes an invalid instruction exception, the exception handler
emulates the hardware floating point operation in software. (see
http://gcc.gnu.org/onlinedocs/gcc-4.0.4/gcc/ARM-Options.html#ARM-Options
for details). The idea is that the same code will work with or without
an FPU, with -msoft-float, you would never see any performance increase
when an FPU is present because it would not be used.

That said, the only off-the-shelf ARM micro-controller with floating
point hardware currently available is the NXP LPC3180, but it uses the
VFP co-processor unit rather than the older FPA co-processor. The
default Newlib builds are for the FPA only, you would have to re-build
it yourself to get VFP support. The consequence of this is that without
a rebuild library FP functions (libm.a) will be software emulated even
when VFP hardware is available.

The solution is simple: don't use -msoft-float. You don't need it, and
it is not always supported. There may be a marginal performance
improvement from not having to do the mode switch on exception, but it
is not significant - it is dog slow either way! Consider avoiding
floating point altogether. And as a general rule, do not use any
non-default compiler options unless you are sure exactly what they do!

Clifford

> The solution is simple: don't use -msoft-float. You don't need it, and
> it is not always supported.

Yes..but I havent specified those switches anywhere.
I still get those errors.

Thanks.

gerard sequeira wrote:
>
> These are the messages i get
>
> "c:\program
> files\yagarto\bin\..\lib\gcc\arm-elf\4.1.1\..\..\..\..\arm-elf\bin\ld.ex e:
> ERROR: startup/libea_startup_thumb.a(framework.o) uses software FP,
> whereas srv1.elf uses hardware FP"
>
> Im using gcc 4.1.1 on the LPC2106 board from olimex.

Your problem is different (you probably should not have chipped in on
Joerg's thread on that basis) srv1.elf is built with the default
hard-float, but framework.o was built with soft-float.

You have to have consistency; either add -msoft-float to the EFLAGS
macro in the make file, or if you are able, rebuild
libea_startup_thumb.a without -msoft-float (I'd recommend the latter if
you have the source and build files).

Clifford

gerard sequeira wrote:
>> The solution is simple: don't use -msoft-float. You don't need it, and
>> it is not always supported.
>
> Yes..but I havent specified those switches anywhere.
> I still get those errors.
>
> Thanks.

This is not your thread, and I was not referring to your problem, which
is different, which is why the solution does not apply! I have however
just answered your problem - hope it helps, but take care not to hijack
other peoples threads.

Clifford Slocombe wrote:
> gerard sequeira wrote:
>>> The solution is simple: don't use -msoft-float. You don't need it, and
>>> it is not always supported.
>>
>> Yes..but I havent specified those switches anywhere.
>> I still get those errors.
>>
>> Thanks.
>
> This is not your thread, and I was not referring to your problem, which
> is different, which is why the solution does not apply! I have however
> just answered your problem - hope it helps, but take care not to hijack
> other peoples threads.

Sorry about that. I didnt mean to.
I'll start a new one.
Thank you for your help