linker error

[Tomdev]

Ok i got errors related like in this post:
http://forums.devkitpro.org/viewtopic.php?f=7&t=348

but the problem is that I'm developing for the nds and not for the gamecube/wii. how can you solve errors like

Code: Select all

undefined reference to `__ctype_ptr__’

I also got these, but solved them with adding -lgcc to the makefile:

Code: Select all

undefined reference to `__aeabi_ldivmod' 
undefined reference to `__errno' 
undefined reference to `__aeabi_idiv'

just some more info: I'm trying to compile with -fPIC and also with -nostdlib. when I delete -nostdlib out the makefile, all the errors are solved, but is there a other way to solve these errors because I don't wantto delete -nostdlib out of my makefile.

regards

Tomdev

[elhobbs]

__errno and __ctype_ptr__ are in libg. so adding -lg to your makefile may fix these particular issues.

one way to track these down is to search the map file for the msiing items when you build without -nostdlib. it will show which lib it is from, then add that lib to the makefile.

[Tomdev]

Okay thanks elhobbs that worked(I have some errors left but it are less )

[WinterMute]

Linking against the supplied libs will cause problems with -fPIC.

The only real way around this, afaik, is to not use anything from the standard libraries in your code. On arm this includes divides since the chip has no native divide instruction.

[Tomdev]

Okay I don't know what to do anymore: I'm trying to compile tremor, In every file stdio, stdlib, errno, strings.h is NOT included. I use function pointers for fopen etc and still i'm getting this error:

Code: Select all

d:/dsi/devkitpro/devkitarm/bin/../lib/gcc/arm-eabi/4.4.0/../../../../arm-eabi/li
b\libc.a(lib_a-abort.o): In function `abort':
(.text+0xc): undefined reference to `_exit'
d:/dsi/devkitpro/devkitarm/bin/../lib/gcc/arm-eabi/4.4.0/../../../../arm-eabi/li
b\libc.a(lib_a-signal.o): In function `_raise_r':
(.text+0x7c): undefined reference to `_getpid_r'
d:/dsi/devkitpro/devkitarm/bin/../lib/gcc/arm-eabi/4.4.0/../../../../arm-eabi/li
b\libc.a(lib_a-signal.o): In function `_raise_r':
(.text+0x8c): undefined reference to `_kill_r'
d:/dsi/devkitpro/devkitarm/bin/../lib/gcc/arm-eabi/4.4.0/../../../../arm-eabi/li
b\libc.a(lib_a-mallocr.o): In function `_malloc_r':
(.text+0x400): undefined reference to `_sbrk_r'
d:/dsi/devkitpro/devkitarm/bin/../lib/gcc/arm-eabi/4.4.0/../../../../arm-eabi/li
b\libc.a(lib_a-mallocr.o): In function `_malloc_r':
(.text+0x47c): undefined reference to `_sbrk_r'
d:/dsi/devkitpro/devkitarm/bin/../lib/gcc/arm-eabi/4.4.0/../../../../arm-eabi/li
b\libc.a(lib_a-freer.o): In function `_malloc_trim_r':
(.text+0x48): undefined reference to `_sbrk_r'
d:/dsi/devkitpro/devkitarm/bin/../lib/gcc/arm-eabi/4.4.0/../../../../arm-eabi/li
b\libc.a(lib_a-freer.o): In function `_malloc_trim_r':
(.text+0x78): undefined reference to `_sbrk_r'
d:/dsi/devkitpro/devkitarm/bin/../lib/gcc/arm-eabi/4.4.0/../../../../arm-eabi/li
b\libc.a(lib_a-freer.o): In function `_malloc_trim_r':
(.text+0xbc): undefined reference to `_sbrk_r'
collect2: ld returned 1 exit status

what's going on here

[WinterMute]

What exactly do you hope to achieve building tremor with -fPIC?

[Tomdev]

sort of plugin, just like moonshell

[WinterMute]

Why are people obsessed with plugins?

devkitARM is a baremetal toolchain, intended for use on targets with little or no supporting OS functions. This makes it incredibly difficult to implement a "plugin" architecture that will ever be anything other than a novelty which is pretty much guaranteed to fail in future iterations of the toolchain.

[Tomdev]

The problem is that I want that other people can write code for the program we're developing too. Also keeping the binary small is a problem. So what's the solution for this?

[elhobbs]

The problem is that I want that other people can write code for the program we're developing too. Also keeping the binary small is a problem. So what's the solution for this?

open source is probably the easiest and least error prone solution. it is not like just anybody is going to be able to write the plugins.

that being said, the plugin approach does hold a certain interest to me despite (or perhaps because of) what wintermute says. It appeals to me for the same reason that writing homebrew applications does - mainly to see if I can do it.