* [Xenomai] Migrating 2.x projects to 3.x...
@ 2017-06-11 14:02 Jim Langston
2017-06-11 15:57 ` Philippe Gerum
0 siblings, 1 reply; 4+ messages in thread
From: Jim Langston @ 2017-06-11 14:02 UTC (permalink / raw)
To: xenomai
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?
Thanks,
Jim
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Xenomai] Migrating 2.x projects to 3.x...
2017-06-11 14:02 [Xenomai] Migrating 2.x projects to 3.x Jim Langston
@ 2017-06-11 15:57 ` Philippe Gerum
2017-06-11 16:36 ` Jim Langston
0 siblings, 1 reply; 4+ messages in thread
From: Philippe Gerum @ 2017-06-11 15:57 UTC (permalink / raw)
To: jlangston, xenomai
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Xenomai] Migrating 2.x projects to 3.x...
2017-06-11 15:57 ` Philippe Gerum
@ 2017-06-11 16:36 ` Jim Langston
2017-06-11 16:51 ` Philippe Gerum
0 siblings, 1 reply; 4+ messages in thread
From: Jim Langston @ 2017-06-11 16:36 UTC (permalink / raw)
To: Philippe Gerum; +Cc: xenomai
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,@../../buildroot-2017.02.2/output/host/usr/i686-buildroot-linux-uclibc/sysroot/usr/lib/cobalt.wrappers
-ltrank
-Wl,@../../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@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.
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Xenomai] Migrating 2.x projects to 3.x...
2017-06-11 16:36 ` Jim Langston
@ 2017-06-11 16:51 ` Philippe Gerum
0 siblings, 0 replies; 4+ messages in thread
From: Philippe Gerum @ 2017-06-11 16:51 UTC (permalink / raw)
To: jlangston; +Cc: xenomai
On 06/11/2017 06:36 PM, Jim Langston wrote:
> 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,@../../buildroot-2017.02.2/output/host/usr/i686-buildroot-linux-uclibc/sysroot/usr/lib/cobalt.wrappers
> -ltrank
> -Wl,@../../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?
>
The Makefile seems to be omitting the --compat flag for the LDFLAGS, you
need to pass --compat to xeno-config for retrieving both the compiler
(--cflags --compat) and linker flags (--ldflags --compat). You should
see -ltrank appearing.
--
Philippe.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2017-06-11 16:51 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-06-11 14:02 [Xenomai] Migrating 2.x projects to 3.x Jim Langston
2017-06-11 15:57 ` Philippe Gerum
2017-06-11 16:36 ` Jim Langston
2017-06-11 16:51 ` Philippe Gerum
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.