Post the whole log. It would be useful to see the linker command line as
well as just the errors.

Clifford Slocombe wrote:
> Post the whole log. It would be useful to see the linker command line as
> well as just the errors.

Here is linker command:
@$(LINKER) \
  -T ../$(LINK_MAP) \
  -Wl,-Map -Wl,Tardis.map -Wl,--cref \
  -DALT_DEBUG \
  -Os \
  -g \
  -Wall \
  -o Dis.elf \
  $(OBJ_FILES) \
  $(O_FILES)

and I do compile with the options -msoft-float -mfpu=fpa

> and I do compile with the options -msoft-float -mfpu=fpa

Here is a list of all my compiling options:
-mno-thumb-interwork -mno-apcs-reentrant -mno-apcs-stack-check
-mlittle-endian -Wpadded -c -mcpu=xscale -msoft-float -mfpu=fpa -g -Os

Dustin Sr wrote:
> Clifford Slocombe wrote:
>> Post the whole log. It would be useful to see the linker command line as
>> well as just the errors.
>
> Here is linker command:
> @$(LINKER) \
>   -T ../$(LINK_MAP) \
>   -Wl,-Map -Wl,Tardis.map -Wl,--cref \
>   -DALT_DEBUG \
>   -Os \
>   -g \
>   -Wall \
>   -o Dis.elf \
>   $(OBJ_FILES) \
>   $(O_FILES)
>
> and I do compile with the options -msoft-float -mfpu=fpa

That is not really what I meant. I meant the actual output from the
build, not the makefile script that created it (you can copy&paste from
a console window - http://www.tech-recipes.com/windows_tips249.html).
That tells us then what all the macros resolve to. And I did mean the
whole log, from the first command to the last error - it might save seve
exchange posts to have it all up front, and it tells more that you might
otherwise think to say.

Many of those options you have are compiler options not linker options.
I have to assume that you are invoking the linker through the compiler
(rather than invoking ld directly) and that these are therefore ignored?

Presumably you do not have FPA hardware (hence the -msoft-float)? I
would remove both the -msoft-float -mfpu=fpa options. You don't need
them to generate floating point code - only to generate floating point
instructions (which will cause an undefined instruction exception and be
handled by FPA emulation code).

I have a project that does have hardware floating point (a VFP rather
than an FPA), and there I use -nostdlibs -lm -lc -lgcc, and have -L
options that point to the .../lib/gcc/arm-elf/4.1.1/fpu/interwork and
.../arm-elf/lib/fpu/interwork directories (which in this case I rebuilt
for VFP). This forces the .elf file to be generated with the correct
libraries (or at least teh libraries I specify). In your case if you
really need to generate FPA instructions (and it seems unlikly that you
do), you should do something similar (except of course you won't need to
rebuild the libraries as I did).


Clifford

Clifford Slocombe wrote:
> Dustin Sr wrote:
>> Clifford Slocombe wrote:
>>> Post the whole log. It would be useful to see the linker command line as
>>> well as just the errors.
>>
>> Here is linker command:
>> @$(LINKER) \
>>   -T ../$(LINK_MAP) \
>>   -Wl,-Map -Wl,Tardis.map -Wl,--cref \
>>   -DALT_DEBUG \
>>   -Os \
>>   -g \
>>   -Wall \
>>   -o Dis.elf \
>>   $(OBJ_FILES) \
>>   $(O_FILES)
>>
>> and I do compile with the options -msoft-float -mfpu=fpa
>
> That is not really what I meant. I meant the actual output from the
> build, not the makefile script that created it (you can copy&paste from
> a console window - http://www.tech-recipes.com/windows_tips249.html).
> That tells us then what all the macros resolve to. And I did mean the
> whole log, from the first command to the last error - it might save seve
> exchange posts to have it all up front, and it tells more that you might
> otherwise think to say.
>
> Many of those options you have are compiler options not linker options.
> I have to assume that you are invoking the linker through the compiler
> (rather than invoking ld directly) and that these are therefore ignored?

Yes I am invoking the linker through the compiler

> I have a project that does have hardware floating point (a VFP rather
> than an FPA), and there I use -nostdlibs -lm -lc -lgcc, and have -L
> options that point to the .../lib/gcc/arm-elf/4.1.1/fpu/interwork and
> .../arm-elf/lib/fpu/interwork directories (which in this case I rebuilt
> for VFP). This forces the .elf file to be generated with the correct
> libraries (or at least teh libraries I specify). In your case if you
> really need to generate FPA instructions (and it seems unlikly that you
> do), you should do something similar (except of course you won't need to
> rebuild the libraries as I did).

Well I don't even need the provided libraries from gnu so I will just
tryit with -nostdlibs.

-Dustin

Dustin Sr wrote:
> Well I don't even need the provided libraries from gnu so I will just
> tryit with -nostdlibs.

It worked thanks. It was actualy -nostdlib .

Dustin

Dustin Sr wrote:

> Well I don't even need the provided libraries from gnu so I will just
> tryit with -nostdlibs.
>
> -Dustin

You'll need at least libgcc.a (-lg) because the compiler generates calls
to this directly as part of normal code code generation even if you do
not make explicit calls. So you will need to specify the library paths
in any case.

However, the first thing you should try is to simply remove the
-msoft-float -mfpu=fpa options. You have not really stated why you need
them. They are normally only used where you want the same code to work
on hardware both with and without an FPA - I can't name a single
off-the-shelf ARM micro that incorporates an FPA, so it is unlikely that
you need this. Without them the compiler uses function calls to do
floating point rather than FPA instructions and software emulation of
the co-processor.

Clifford

Dustin Sr wrote:
> Dustin Sr wrote:
>> Well I don't even need the provided libraries from gnu so I will just
>> tryit with -nostdlibs.
>
> It worked thanks. It was actualy -nostdlib .
>
> Dustin

Oops cross-posted. Your milage may vary I guess. I still say that you
probably don't want the FPA code generation.