On 05/30/2017 12:23 PM, Fyleo wrote: > On 30/05/2017 09:12, Philippe Gerum wrote: >> On 05/29/2017 11:19 PM, Fyleo wrote: >>> Hello all, >>> >>> I'm trying to port machinekit (machinekit.io) to xenomai 3.0.4 which >>> support only xenomai 2.6.4 for the moment. >>> >>> This software is design this way : >>> >>> A : main executable >>> >>> B : shared library abstracting thread API, with one library for posix, >>> for xenomai, ... >>> >>> The xenomai B library is linked against alchemy, copperplate, ... >>> (xeno-config --ldflags --auto-init-solib --skin=alchemy) >>> >>> The program works in a way that, at start time, it load with dlopen the >>> configured API (B). >>> >>> My problem is that dlopen(with RTLD_GLOBAL|RTLD_NOW) fail with the error >>> : "/usr/lib/libcopperplate.so.0: undefined symbol: main" >>> >> Could you pick the change below and retry? Feedback welcome. >> >> http://git.xenomai.org/xenomai-3.git/commit/?id=48b2e57e29ca1c33eba14abb4b5eaa15431130fa >> >> > Hi, > > This fix works, thanks. > > But will it always work in executable auto init ? The symbol > "__real_main" have to be defined in user code if linked with bootstrap.o ? >
__real_main() stands for the actual main as generated by the linker when the auto-bootstrap feature is in effect (i.e. --wrap=main --dynamic-list=...), and bootstrap.o is glued to executables/DSOs only in such a case. IOW, __real_main() is guaranteed to exist if bootstrap.o is part of the binary image. So yes, we should be safe. This change has been tested with the alchemy testsuite which is copperplate-based, a C++ application enabling auto-init-solib, and Xenomai's base utility programs enabling the auto-bootstrap, so far so good. -- Philippe. _______________________________________________ Xenomai mailing list [email protected] https://xenomai.org/mailman/listinfo/xenomai
