[Xenomai] Migrating 2.x projects to 3.x...

Jim Langston jim.langston at gmail.com
Sun Jun 11 18:36:33 CEST 2017


Ok, opted for the compatibility layer (actual make file):

APP = rfiserver
XENOCONFIG:=../../buildroot-2017.02.2/output/host/usr/i686-buildroot-linux-uclibc/sysroot/usr/bin/xeno-config
CC = $(shell ${XENOCONFIG} --native --posix --compat --cc)
CFLAGS = $(shell ${XENOCONFIG} --native --posix --compat --cflags)
LDFLAGS = $(shell ${XENOCONFIG} --native --posix --compat --ldflags)

all: clean $(APP)
$(APP): $(APP).c sys_svr.c front_panel.c test.cpp
    $(CC) $(CFLAGS) $(LDFLAGS) sys_svr.c front_panel.c test.cpp -o $@ $<
    cp rfiserver ../root/bin/
clean:
    rm -f *.o $(APP) *~
.PHONY: clean


So now I get the following output when I run 'make':

/home/jlangston/mi/xenomai3/buildroot-2017.02.2/output/host/usr/bin/i686-buildroot-linux-uclibc-gcc
-I../../buildroot-2017.02.2/output/host/usr/i686-buildroot-linux-uclibc/sysroot/usr/include/xenomai/trank/posix
-I../../buildroot-2017.02.2/output/host/usr/i686-buildroot-linux-uclibc/sysroot/usr/include/xenomai/trank
-D__XENO_COMPAT__
-I../../buildroot-2017.02.2/output/host/usr/i686-buildroot-linux-uclibc/sysroot/usr/include/xenomai/cobalt
-I../../buildroot-2017.02.2/output/host/usr/i686-buildroot-linux-uclibc/sysroot/usr/include/xenomai
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os
-D_GNU_SOURCE -D_REENTRANT -D__COBALT__
-I../../buildroot-2017.02.2/output/host/usr/i686-buildroot-linux-uclibc/sysroot/usr/include/xenomai/alchemy
-D__COBALT_WRAP__ -Wl,--no-as-needed
-Wl, at ../../buildroot-2017.02.2/output/host/usr/i686-buildroot-linux-uclibc/sysroot/usr/lib/cobalt.wrappers
-ltrank
-Wl, at ../../buildroot-2017.02.2/output/host/usr/i686-buildroot-linux-uclibc/sysroot/usr/lib/modechk.wrappers
-lalchemy -lcopperplate
../../buildroot-2017.02.2/output/host/usr/i686-buildroot-linux-uclibc/sysroot/usr/lib/xenomai/bootstrap.o
-Wl,--wrap=main
-Wl,--dynamic-list=../../buildroot-2017.02.2/output/host/usr/i686-buildroot-linux-uclibc/sysroot/usr/lib/dynlist.ld
-L../../buildroot-2017.02.2/output/host/usr/i686-buildroot-linux-uclibc/sysroot/usr/lib
-lcobalt -lmodechk -lpthread -lrt    sys_svr.c front_panel.c test.cpp -o
rfiserver rfiserver.c

But I still get the 'undefined' references to the 'rt_dev_XXX()' calls.

If I replace all of the 'rt_dev_XXX' calls with the plain POSIX variants
(remove all of the 'rt_dev_ prefixes), then the errors go away, but is this
because I'm not enabling the compatibility layer correctly, and I'm linking
unwrapped APIs?



On Sun, Jun 11, 2017 at 11:57 AM, Philippe Gerum <rpm at xenomai.org> wrote:

> On 06/11/2017 04:02 PM, Jim Langston wrote:
> > Hello,
> >
> > I have been attempting to port over a project building using a quite old
> > version of Xenomai (2.4.10 on kernel 2.6.30.5) to 3.x on kernel 4.1.18.
> >
> > I have read through the Migration guide, and have made the following
> > changes based on what I saw needed changing:
> >
> > - Removed all references to 'native/intr.h', since that doesn't exist any
> > more
> > - 'T_PRIMARY' flag for 'rt_task_set_mode()' doesn't exist, so replace
> with
> > 'T_CONFORMING'
> > - In the makefiles, pass '--native --compat' to 'xeno-config'
> >
> > This seems to make everything build and link with a minimum of fuss, no
> > undefined items, link errors, etc.
> >
> > Unfortunately, for my applications that connect to drivers, I get the
> > following:
> >
> >
> > *front_panel.c:144:10: warning: implicit declaration of function
> > ‘rt_dev_ioctl’ [-Wimplicit-function-declaration]*
> > I get this for basically all functions starting with 'rt_dev_'.  There
> is a
> > mention of it in the Migration Guide.
> >
> > So my question is:  Do I need to manually replace all calls to 'rt_dev_'
> > with 'rt_' calls, or is my compatibility library not being linked in
> > properly?
> >
>
> You have three options:
>
> 1. convert the rt_dev* calls to their POSIX counterpart as provided by
> libcobalt. Assuming you don't use the symbol wrapping [1], you would
> need to explicitly pull the libcobalt symbols, e.g. __RT(ioctl(...)) for
> replacing calls to rt_dev_ioctl(). If you do wrap the symbols, then
> calling ioctl() would be enough.
>
> 2. enable the compat layer (aka libtrank), by passing the --compat flag
> to xeno-config. This would cause compat definitions and code to be
> interposed when building, including the obsolete rt_dev* API.
>
> 3. hack away by directly pulling include/trank/rtdm/rtdm.h, which
> defines what you need.
>
> The reasoning behind this change is that Xenomai 3 bases everything on
> libcobalt's POSIX implementation in dual kernel mode, so adding yet
> another interface such as rt_dev* only to wrap names became useless noise.
>
> [1]
> http://xenomai.org/2014/08/porting-a-linux-application-
> to-xenomai-dual-kernel/#Under_the_hood_the_8211wrap_flag
>
> --
> Philippe.
>


More information about the Xenomai mailing list