EmbDev.net

Forum: ARM programming with GCC/GNU tools Linker problem


von Starter (Guest)


Rate this post
useful
not useful
I have used arm-elf-gcc at many times with Cstartup.S and Windows
Program must run under ARM.
When have tried change c to c++ caused this error:

Linking: main.elf
arm-elf-gcc  -mcpu=arm7tdmi  -I. -gdwarf-2 -DROM_RUN -DVECTORS_ROM  -Os
-Wall -W
cast-align -Wimplicit  -Wpointer-arith -Wswitch -Wredundant-decls
-Wreturn-type
-Wshadow -Wunused -Wa,-adhlns=Cstartup.lst   -MD -MP -MF .dep/main.elf.d
Cstartu
p.o       main.o mem_seg.o mem_seg_impl.o segment.o Cstartup_SAM7.o
blinker.o li
b_AT91SAM7X256.o std_comm.o --output main.elf -nostartfiles
-Wl,-Map=main.map,--
cref -shared  -lm -lc -lgcc -dead_strip  -lstdc++ --gc-sections
-TAT91SAM7x256-R
OM.ld
c:/winarm/bin/../lib/gcc/arm-elf/4.1.0/../../../../arm-elf/lib\libstdc++ 
.a(eh_pe
rsonality.o): In function
`read_encoded_value_with_base':c:/winarms/gcc-4.1.0/gc
c/unwind-pe.h:259: undefined reference to `abort'
c:/winarm/bin/../lib/gcc/arm-elf/4.1.0/../../../../arm-elf/lib\libstdc++ 
.a(eh_pe
rsonality.o): In function
`base_of_encoded_value':c:/winarms/gcc-4.1.0/gcc/unwin
d-pe.h:122: undefined reference to `abort'
:c:/winarms/gcc-4.1.0/gcc/unwind-pe.h:122: undefined reference to
`abort'
c:/winarm/bin/../lib/gcc/arm-elf/4.1.0/../../../../arm-elf/lib\libstdc++ 
.a(eh_pe
rsonality.o): In function
`size_of_encoded_value':c:/winarms/gcc-4.1.0/gcc/unwin
d-pe.h:90: undefined reference to `abort'
c:/winarm/bin/../lib/gcc/arm-elf/4.1.0/../../../../arm-elf/lib\libstdc++ 
.a(eh_te
rminate.o): In function `__cxxabiv1::__terminate(void
(*)())':../../../../../gcc
-4.1.0/libstdc++-v3/libsupc++/eh_terminate.cc:44: undefined reference to
`abort'

etc. etc.
common functions seems missing.
I have read some issues like this but cannot find a solution. Any ideas?

von Martin T. (mthomas) (Moderator)


Rate this post
useful
not useful
Starter wrote:
> I have used arm-elf-gcc at many times with Cstartup.S and Windows
> Program must run under ARM.

... so you are not "Starter"... I realy like real names or at least
names that sound like real names. Anyway.

> When have tried change c to c++ caused this error:
>...
>c:/winarm/bin/../lib/gcc/arm-elf/4.1.0/../../../../arm-elf/lib\libstdc+ +.a(eh_pe
> rsonality.o): In function
> `read_encoded_value_with_base':c:/winarms/gcc-4.1.0/gc
> c/unwind-pe.h:259: undefined reference to `abort'
>...

So how about just providing a function with this name. I used this code
in my few C++ Examples:

void abort(void)
{
  while(1);
}


Martin Thomas

von Starter (Guest)


Rate this post
useful
not useful
Martin Thomas wrote:

> ... so you are not "Starter"... I realy like real names or at least
> names that sound like real names. Anyway.
Excuse me - my name is well-known in my surroundings and I don't like
fake "real" names. Please, leave me some privacy.

>> When have tried change c to c++ caused this error:
>>...
>>c:/winarm/bin/../lib/gcc/arm-elf/4.1.0/../../../../arm-elf/lib\libstdc 
++.a(eh_pe
>> rsonality.o): In function
>> `read_encoded_value_with_base':c:/winarms/gcc-4.1.0/gc
>> c/unwind-pe.h:259: undefined reference to `abort'
>>...
>
> So how about just providing a function with this name. I used this code
> in my few C++ Examples:
>
> void abort(void)
> {
>   while(1);
> }
I think this is not solution here. There are many functions like this
(not only "abort") and these maybe needed. I think this is a compiler
(linker) internal error and caused by library search mismatch. I can
turn this error on and off simply use one (1) expression: queue. If use,
it occurs this error.

von Martin T. (mthomas) (Moderator)


Rate this post
useful
not useful
>> [...]
>> So how about just providing a function with this name. I used this code
>> in my few C++ Examples:
>>
>> void abort(void)
>> {
>>   while(1);
>> }
> I think this is not solution here.
Why? What do you expect as "solution"? Since you do not have a system to
abort to there is not much you can do in this syscall. Of cause some
additional code can be implemented here (blink LED, send debug-output,
watchdog-reset...)

> There are many functions like this
> (not only "abort") and these maybe needed.
You did not mention the names so it's difficult to help here. I guess
the missing functions are the usual syscall which the libstdc++ relies
on to interface with he hardware (sbrk, read, write, etc).

> I think this is a compiler
> (linker) internal error and caused by library search mismatch.
I'm pretty sure that there is no "compiler (linker) internal error".
Maybe a search-problem a something with library-ordering. But not an
internal error.

> I can
> turn this error on and off simply use one (1) expression: queue. If use,
> it occurs this error.
Which queue? From the c++ (ST)-library? This should be the reason why
the syscalls are needed and you see the linker-errors. Since the c++-
RTL queue needs some syscalls, at least sbrk as interface to the heap.
In some configurations you may try -lnosys to bring in a "generic" sbrk
without writing own code (take care to provide end, see linker-script).

von Starter (Guest)


Rate this post
useful
not useful
Martin Thomas wrote:
> Why? What do you expect as "solution"? Since you do not have a system to
> abort to there is not much you can do in this syscall. Of cause some
> additional code can be implemented here (blink LED, send debug-output,
> watchdog-reset...)
You are right in here but there are another functions.

>> There are many functions like this
>> (not only "abort") and these maybe needed.
> You did not mention the names so it's difficult to help here. I guess
> the missing functions are the usual syscall which the libstdc++ relies
> on to interface with he hardware (sbrk, read, write, etc).
Yes. These ones, isatty and other file functions. No files, op. system
and terminal at this system of course.

>> I can
>> turn this error on and off simply use one (1) expression: queue. If use,
>> it occurs this error.
> Which queue? From the c++ (ST)-library? This should be the reason why
> the syscalls are needed and you see the linker-errors. Since the c++-
> RTL queue needs some syscalls, at least sbrk as interface to the heap.
> In some configurations you may try -lnosys to bring in a "generic" sbrk
> without writing own code (take care to provide end, see linker-script).
-lnosys exists but has no effect.

I have get an advice to implement my own queue. Is there an only
solution - or write fake calls like fread, and all others?
Is there any example program without these functions?

I have thought programmers of libraries solved this problem at any way.

Please log in before posting. Registration is free and takes only a minute.
Existing account
Do you have a Google/GoogleMail account? No registration required!
Log in with Google account
No account? Register here.