[riot-devel] using the native-port for development
ludwig.ortmann at fu-berlin.de
Wed May 15 09:13:39 CEST 2013
this is known and partly necessary behavior.
ld-linux (or some other platforms equivalent) is definitely needed as
the port uses system calls instead of hardware (timers, character device
libc is needed for, well, the c library .. things like printf.
Toolchains for other platforms contain c libraries as well, only they
are not dynamically linked.
I don't see a reason against dynamic linking per se for the native port.
It could turn out to be necessary to replace certain functions though,
so maybe a custom native toolchain will be in order at some point.
libpthread - I'm not sure if it's inevitable. In general the same
reasoning as above applies.
librt is on its way out.
By the way - I pushed some changes to my fork yesterday to resolve the
"context switching is unreliable" issue. I'll be merging this with
upstream and fix some remaining problems now.
If you run into "strange behavior" it could pay to use the fork
already.. I don't know how out of sync it is, yet ;-)
On 05/14/2013 06:49 PM, Martin L. wrote:
> Dear RIOT developers,
> we are currently testing out to develop with the native port of RIOT
> which is awesome compared to debugging and dealing with plain sensor-nodes and evaluation platforms.
> We figured out that the resulting elf binary using the native port always links to 4 system .so files.
> $ldd default-native.elf
> librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xb76f6000)
> libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb754c000)
> libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb7530000)
> /lib/ld-linux.so.2 (0xb7716000)
> (In case of an ARM build, say msba2, no linked resources are in use.)
> I would like to ask if this is a known behaviour and if there is a way to isolate the native .elf completely from system dependencies?
> Best regards,
> devel mailing list
> devel at riot-os.org
More information about the devel