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.
(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?
ld-linux (or some other platforms equivalent) is definitely needed as the port uses system calls instead of hardware (timers, character device etc.).
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
ld-linux (or some other platforms equivalent) is definitely needed as
the port uses system calls instead of hardware (timers, character device
etc.).
To correct myself:
ld-linux.so is needed for dynamic library loading .. I was thinking of
linux-gate.so when I wrote the above (prior to coffee intake).
libpthread - I'm not sure if it's inevitable. In general the same
reasoning as above applies.
librt is on its way out.
librt is already out in the fork. libpthread seems to be a dependency of
librt, it went with librt.
I forgot to ask - is there any particular reason why you want to get rid
of the libraries?
In fact we are about to port some c++11 libraries/programs from native linux to RIOT.
We try to create an "abstraction wrapper" to enable them being runnable on RIOT
without the need of heavy refectoring.
In the current state the native RIOT environment enables to access/create native threads and mutexes,
which happens in some cases and results in RIOT to crash (as expected).
I think a more bounded native RIOT environment would reveal and prevent such "hidden" dependencies/relations and
could ease platform independant development and portability.
In fact we are about to port some c++11 libraries/programs from native linux to RIOT.
We try to create an "abstraction wrapper" to enable them being runnable on RIOT
without the need of heavy refectoring.
In the current state the native RIOT environment enables to access/create native threads and mutexes,
which happens in some cases and results in RIOT to crash (as expected).
Is this still the case with the current fork? I got rid of librt which pulled in pthreads, so maybe it is already fixed. (The fork is in sync with upstream now, so you should be able to check this without much hassle..)
I think a more bounded native RIOT environment would reveal and prevent such "hidden" dependencies/relations and
could ease platform independant development and portability.
I see.
g++/gcc does have some options dealing with library inclusion/exclusion (e.g. -nodefaultlibs).
As I have no experience with compiling c++ I don't know what c++11 needs to work, what the other toolchains provide etc. I'd suggest you try and figure out if these options can be used to limit RIOT to libc and whatever set of libraries is required and available in the target toolchains.
the lrt option for native board didn't made it out of the Makefile.include in the current branch.
I removed it by hand and the everything seems to be as you said .
Am Im 'allowed' to remove the lrt option and push it, or is there still reason to keep it in?
Im currently experiment with c++11 features and c++ with a cross gcc above 4.7.0.
When I set -std=gnu++0x in the CFLAGS, g++ becomes a little picky.
I started to fix the resulting 'errors' which occur in different parts of RIOT and board sources.
Most of them are pointer conversion issues (e.g. void* to FP and back) and declarations of
an iterating variable inside for-loop.
I would like to push the changes up (one by one according to the coding conventions ),
but I cannot tell if everything will work seamless in all configurations.
I would like to know if someone's concerned about it,
and if there is test-suite or test procedure for such changes?
the lrt option for native board didn't made it out of the Makefile.include
in the current branch.
...
Am Im 'allowed' to remove the lrt option and push it, or is there still
reason to keep it in?
It looks like I'm going to pull the current native changes upstream today,
so I guess you could just wait for that to happen.
On the other hand, if you want to push before I guess there will be no
trouble merging this, so go ahead
I would like to push the changes up (one by one according to the coding
conventions ),
but I cannot tell if everything will work seamless in all configurations.
Not sure if that is what you mean, but I guess it doesn't make much sense
to break up pull requests, does it?
I would like to know if someone's concerned about it,
and if there is test-suite or test procedure for such changes?
I'm in the same situation right now (about to pull, not certain whether
all platforms work).
I don't know its state, but I remember we had a build bot ... some form of
CI server would be great! Oleg? Anyone?
I don't know its state, but I remember we had a build bot ... some form of
CI server would be great! Oleg? Anyone?
you're totally right. An automatic test environment for CI would be very
beneficial. Unfortunately, the old build bot (buildbot.imp.fu-berlin.de) would
need some maintenance and new configuration as he still does not know anything
about RIOT (he is still happily testing �kleos, I guess).
Are there any volunteers to take care of reconfiguring the build bot? [1]
I could take care of manual maintenance and connect the several supported
hardware platforms. So far it's only equipped with a MSB-A2.
I don’t know its state, but I remember we had a build bot … some form of
CI server would be great! Oleg? Anyone?
you’re totally right. An automatic test environment for CI would be very
beneficial. Unfortunately, the old build bot (buildbot.imp.fu-berlin.de) would
need some maintenance and new configuration as he still does not know anything
about RIOT (he is still happily testing µkleos, I guess).
Are there any volunteers to take care of reconfiguring the build bot? [1]
I could take care of manual maintenance and connect the several supported
hardware platforms. So far it’s only equipped with a MSB-A2.
>Are there any volunteers to take care of reconfiguring the build bot? [1]
>I could take care of manual maintenance and connect the several supported
>hardware platforms. So far it's only equipped with a MSB-A2.
I can do that. Do I still have access to the VM?
I guess you have. Tell me if your credentials are not working.
.