[Xenomai] Order options to build a Xenomai program

[Xenomai] Order options to build a Xenomai program

[Leopold Palomo-Avellaneda]

Hi,


I resend this message to the list now that it has again more activity. Maybe
some of you cold help me to understand what is wrong here. I'm sorry if it's not
appropriate to send again a message to the list.

=====

I have an strange problem and I would like to ask if some clever mind
can help me.

I'm trying to build with cmake (this story is for another mail) a simple
example [1] with xenomai 3.0.7. I have some custom macros that basically
uses the information from xeno-config.

I can build and run the example with the Makefile below in the email. It
just works.

Narrowing the problem I have obtained the exactly call made by the
Makefile created by cmake. It compiles the file using:

$ /usr/bin/cc   -I/usr/include/xenomai/trank
-I/usr/include/xenomai/cobalt -I/usr/include/xenomai
-I/usr/include/xenomai/alchemy  -D__XENO_COMPAT__ -g -O2
-fdebug-prefix-map=/build/xenomai-3.0.7+ds1=. -fstack-protector-strong
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2
-fno-omit-frame-pointer -D_GNU_SOURCE -D_REENTRANT
-fasynchronous-unwind-tables -D__COBALT__ -o
CMakeFiles/rtprint.dir/rtprint.c.o   -c
/home/leopold.palomo/xenomai/cmake/src/native/rtprint.c


and links the file using:

$ /usr/bin/cc    -Wl,--no-as-needed
-Wl,@/usr/lib/x86_64-linux-gnu/modechk.wrappers
/usr/lib/x86_64-linux-gnu/xenomai/bootstrap.o -Wl,--wrap=main
-Wl,--dynamic-list=/usr/lib/x86_64-linux-gnu/dynlist.ld -Wl,-z,relro
-Wl,-z,now -Wl,--as-needed -pthread CMakeFiles/rtprint.dir/rtprint.c.o
-o rtprint -rdynamic -ltrank -lalchemy -lcopperplate -lcobalt -lmodechk
-lpthread -lrt -lfuse


Using the Makefile attached, to compile, make call gcc with:

$ make rtprint.o
gcc -c -o rtprint.o rtprint.c -I/usr/include/xenomai/trank
-D__XENO_COMPAT__ -I/usr/include/xenomai/cobalt -I/usr/include/xenomai
-g -O2 -fdebug-prefix-map=/build/xenomai-3.0.7+ds1=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -fno-omit-frame-pointer -D_GNU_SOURCE -D_REENTRANT
-fasynchronous-unwind-tables -D__COBALT__ -I/usr/include/xenomai/alchemy

and link with:

$ make rtprint
gcc -o rtprint rtprint.o -Wl,--no-as-needed -ltrank
-Wl,@/usr/lib/x86_64-linux-gnu/modechk.wrappers -lalchemy -lcopperplate
/usr/lib/x86_64-linux-gnu/xenomai/bootstrap.o -Wl,--wrap=main
-Wl,--dynamic-list=/usr/lib/x86_64-linux-gnu/dynlist.ld
-L/usr/lib/x86_64-linux-gnu -lcobalt -lmodechk -lpthread -lrt
-Wl,-z,relro -Wl,-z,now -Wl,--as-needed   -lfuse -pthread


The build result made by CMake is: rtprint (24816 bytes) and rtprint.o
(16408 bytes)

The build result make using the makefile: rtprint (24720 bytes) and
rtprint.o (16312 bytes).

If I call the gcc directly I obtain the same bytes. The difference is
the stored path. If I strip the executables the size is the same (10224
bytes) but binaries differ.

But, and here is the problem. If I run the cmake product I obtain:

/rtprint
./rtprint: symbol lookup error:
/usr/lib/x86_64-linux-gnu/libcopperplate.so.0: undefined symbol:
__real_malloc


and the produced with make runs.

The produced using cmake has:

$ ldd rtprint
	linux-vdso.so.1 (0x00007ffd0e1e1000)
	libtrank.so.0 => /usr/lib/x86_64-linux-gnu/libtrank.so.0
(0x00007f7b5dec9000)
	libalchemy.so.0 => /usr/lib/x86_64-linux-gnu/libalchemy.so.0
(0x00007f7b5dcb7000)
	libcopperplate.so.0 => /usr/lib/x86_64-linux-gnu/libcopperplate.so.0
(0x00007f7b5da9f000)
	libcobalt.so.2 => /usr/lib/x86_64-linux-gnu/libcobalt.so.2
(0x00007f7b5d87d000)
	libfuse.so.2 => /lib/x86_64-linux-gnu/libfuse.so.2 (0x00007f7b5d63f000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007f7b5d422000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7b5d083000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f7b5e2d0000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f7b5ce7b000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f7b5cc77000)


and with make

$ ldd rtprint
	linux-vdso.so.1 (0x00007ffffcfe2000)
	libtrank.so.0 => /usr/lib/x86_64-linux-gnu/libtrank.so.0
(0x00007f621304f000)
	libalchemy.so.0 => /usr/lib/x86_64-linux-gnu/libalchemy.so.0
(0x00007f6212e3d000)
	libcopperplate.so.0 => /usr/lib/x86_64-linux-gnu/libcopperplate.so.0
(0x00007f6212c25000)
	libcobalt.so.2 => /usr/lib/x86_64-linux-gnu/libcobalt.so.2
(0x00007f6212a03000)
	libmodechk.so.0 => /usr/lib/x86_64-linux-gnu/libmodechk.so.0
(0x00007f6212801000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007f62125e4000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f62123dc000)
	libfuse.so.2 => /lib/x86_64-linux-gnu/libfuse.so.2 (0x00007f621219e000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6211dff000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f6213456000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6211bfb000)


pay attention that first one is not linked against libmodechk, although
is specified in the call.


I have not found any difference, only the order, so I am really
overwhelmed. Any idea?


Best regards,


Leopold



Makefile
-------------------------------------------------------------------
###### CONFIGURATION ######

### List of applications to be build
APPLICATIONS = rtprint

### Default Xenomai installation path
XENO ?= /usr/xenomai

XENOCONFIG=$(shell PATH=$(XENO):$(XENO)/bin:$(PATH) which xeno-config
2>/dev/null)

CC=$(shell $(XENOCONFIG) --cc)

CFLAGS=$(shell $(XENOCONFIG) --skin=native --cflags)

LDFLAGS=$(shell $(XENOCONFIG) --skin=native --ldflags)

%.o: %.c
	$(CC) -c -o $@ $< $(CFLAGS)

rtprint: rtprint.o
	$(CC) -o $@ rtprint.o $(LDFLAGS)

clean:
	$(RM) $(APPLICATIONS) *.o

all: $(APPLICATIONS)
-------------------------------------------------------------------


[1]
https://gitlab.denx.de/Xenomai/xenomai/blob/eol/v2.6.x/examples/native/rtprint.c



-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Re: [Xenomai] Order options to build a Xenomai program

[Henning Schild]

Hey,

i personally am a bit overwhelmed with the amount of information, and i
could not clearly spot the issue you seem to have.

But you might want to have a look at:
https://github.com/nolange/cmake_xenomai

Henning

Am Thu, 6 Sep 2018 11:52:39 +0200
schrieb Leopold Palomo-Avellaneda <leo@alaxarxa.net>:

> Hi,
> 
> 
> I resend this message to the list now that it has again more
> activity. Maybe some of you cold help me to understand what is wrong
> here. I'm sorry if it's not appropriate to send again a message to
> the list.
> 
> =====
> 
> I have an strange problem and I would like to ask if some clever mind
> can help me.
> 
> I'm trying to build with cmake (this story is for another mail) a
> simple example [1] with xenomai 3.0.7. I have some custom macros that
> basically uses the information from xeno-config.
> 
> I can build and run the example with the Makefile below in the email.
> It just works.
> 
> Narrowing the problem I have obtained the exactly call made by the
> Makefile created by cmake. It compiles the file using:
> 
> $ /usr/bin/cc   -I/usr/include/xenomai/trank
> -I/usr/include/xenomai/cobalt -I/usr/include/xenomai
> -I/usr/include/xenomai/alchemy  -D__XENO_COMPAT__ -g -O2
> -fdebug-prefix-map=/build/xenomai-3.0.7+ds1=. -fstack-protector-strong
> -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2
> -fno-omit-frame-pointer -D_GNU_SOURCE -D_REENTRANT
> -fasynchronous-unwind-tables -D__COBALT__ -o
> CMakeFiles/rtprint.dir/rtprint.c.o   -c
> /home/leopold.palomo/xenomai/cmake/src/native/rtprint.c
> 
> 
> and links the file using:
> 
> $ /usr/bin/cc    -Wl,--no-as-needed
> -Wl,@/usr/lib/x86_64-linux-gnu/modechk.wrappers
> /usr/lib/x86_64-linux-gnu/xenomai/bootstrap.o -Wl,--wrap=main
> -Wl,--dynamic-list=/usr/lib/x86_64-linux-gnu/dynlist.ld -Wl,-z,relro
> -Wl,-z,now -Wl,--as-needed -pthread CMakeFiles/rtprint.dir/rtprint.c.o
> -o rtprint -rdynamic -ltrank -lalchemy -lcopperplate -lcobalt
> -lmodechk -lpthread -lrt -lfuse
> 
> 
> Using the Makefile attached, to compile, make call gcc with:
> 
> $ make rtprint.o
> gcc -c -o rtprint.o rtprint.c -I/usr/include/xenomai/trank
> -D__XENO_COMPAT__ -I/usr/include/xenomai/cobalt -I/usr/include/xenomai
> -g -O2 -fdebug-prefix-map=/build/xenomai-3.0.7+ds1=.
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
> -D_FORTIFY_SOURCE=2 -fno-omit-frame-pointer -D_GNU_SOURCE -D_REENTRANT
> -fasynchronous-unwind-tables -D__COBALT__
> -I/usr/include/xenomai/alchemy
> 
> and link with:
> 
> $ make rtprint
> gcc -o rtprint rtprint.o -Wl,--no-as-needed -ltrank
> -Wl,@/usr/lib/x86_64-linux-gnu/modechk.wrappers -lalchemy
> -lcopperplate /usr/lib/x86_64-linux-gnu/xenomai/bootstrap.o
> -Wl,--wrap=main
> -Wl,--dynamic-list=/usr/lib/x86_64-linux-gnu/dynlist.ld
> -L/usr/lib/x86_64-linux-gnu -lcobalt -lmodechk -lpthread -lrt
> -Wl,-z,relro -Wl,-z,now -Wl,--as-needed   -lfuse -pthread
> 
> 
> The build result made by CMake is: rtprint (24816 bytes) and rtprint.o
> (16408 bytes)
> 
> The build result make using the makefile: rtprint (24720 bytes) and
> rtprint.o (16312 bytes).
> 
> If I call the gcc directly I obtain the same bytes. The difference is
> the stored path. If I strip the executables the size is the same
> (10224 bytes) but binaries differ.
> 
> But, and here is the problem. If I run the cmake product I obtain:
> 
> /rtprint
> ./rtprint: symbol lookup error:
> /usr/lib/x86_64-linux-gnu/libcopperplate.so.0: undefined symbol:
> __real_malloc
> 
> 
> and the produced with make runs.
> 
> The produced using cmake has:
> 
> $ ldd rtprint
> 	linux-vdso.so.1 (0x00007ffd0e1e1000)
> 	libtrank.so.0 => /usr/lib/x86_64-linux-gnu/libtrank.so.0
> (0x00007f7b5dec9000)
> 	libalchemy.so.0 => /usr/lib/x86_64-linux-gnu/libalchemy.so.0
> (0x00007f7b5dcb7000)
> 	libcopperplate.so.0
> => /usr/lib/x86_64-linux-gnu/libcopperplate.so.0 (0x00007f7b5da9f000)
> 	libcobalt.so.2 => /usr/lib/x86_64-linux-gnu/libcobalt.so.2
> (0x00007f7b5d87d000)
> 	libfuse.so.2 => /lib/x86_64-linux-gnu/libfuse.so.2
> (0x00007f7b5d63f000) libpthread.so.0
> => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f7b5d422000)
> 	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
> (0x00007f7b5d083000) /lib64/ld-linux-x86-64.so.2 (0x00007f7b5e2d0000)
> 	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1
> (0x00007f7b5ce7b000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2
> (0x00007f7b5cc77000)
> 
> 
> and with make
> 
> $ ldd rtprint
> 	linux-vdso.so.1 (0x00007ffffcfe2000)
> 	libtrank.so.0 => /usr/lib/x86_64-linux-gnu/libtrank.so.0
> (0x00007f621304f000)
> 	libalchemy.so.0 => /usr/lib/x86_64-linux-gnu/libalchemy.so.0
> (0x00007f6212e3d000)
> 	libcopperplate.so.0
> => /usr/lib/x86_64-linux-gnu/libcopperplate.so.0 (0x00007f6212c25000)
> 	libcobalt.so.2 => /usr/lib/x86_64-linux-gnu/libcobalt.so.2
> (0x00007f6212a03000)
> 	libmodechk.so.0 => /usr/lib/x86_64-linux-gnu/libmodechk.so.0
> (0x00007f6212801000)
> 	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
> (0x00007f62125e4000)
> 	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1
> (0x00007f62123dc000) libfuse.so.2
> => /lib/x86_64-linux-gnu/libfuse.so.2 (0x00007f621219e000) libc.so.6
> => /lib/x86_64-linux-gnu/libc.so.6
> (0x00007f6211dff000) /lib64/ld-linux-x86-64.so.2 (0x00007f6213456000)
> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6211bfb000)
> 
> 
> pay attention that first one is not linked against libmodechk,
> although is specified in the call.
> 
> 
> I have not found any difference, only the order, so I am really
> overwhelmed. Any idea?
> 
> 
> Best regards,
> 
> 
> Leopold
> 
> 
> 
> Makefile
> -------------------------------------------------------------------
> ###### CONFIGURATION ######
> 
> ### List of applications to be build
> APPLICATIONS = rtprint
> 
> ### Default Xenomai installation path
> XENO ?= /usr/xenomai
> 
> XENOCONFIG=$(shell PATH=$(XENO):$(XENO)/bin:$(PATH) which xeno-config
> 2>/dev/null)  
> 
> CC=$(shell $(XENOCONFIG) --cc)
> 
> CFLAGS=$(shell $(XENOCONFIG) --skin=native --cflags)
> 
> LDFLAGS=$(shell $(XENOCONFIG) --skin=native --ldflags)
> 
> %.o: %.c
> 	$(CC) -c -o $@ $< $(CFLAGS)
> 
> rtprint: rtprint.o
> 	$(CC) -o $@ rtprint.o $(LDFLAGS)
> 
> clean:
> 	$(RM) $(APPLICATIONS) *.o
> 
> all: $(APPLICATIONS)
> -------------------------------------------------------------------
> 
> 
> [1]
> https://gitlab.denx.de/Xenomai/xenomai/blob/eol/v2.6.x/examples/native/rtprint.c
> 
> 
> 

Re: [Xenomai] Order options to build a Xenomai program

[Per Oberg]

----- Den 13 sep 2018, på kl 10:54, Henning Schild henning.schild@siemens.com skrev:

> Hey,

> i personally am a bit overwhelmed with the amount of information, and i
> could not clearly spot the issue you seem to have.

> But you might want to have a look at:
> https://github.com/nolange/cmake_xenomai

> Henning

> Am Thu, 6 Sep 2018 11:52:39 +0200
> schrieb Leopold Palomo-Avellaneda <leo@alaxarxa.net>:

> > Hi,


> > I resend this message to the list now that it has again more
> > activity. Maybe some of you cold help me to understand what is wrong
> > here. I'm sorry if it's not appropriate to send again a message to
> > the list.

> > =====

> > I have an strange problem and I would like to ask if some clever mind
> > can help me.

> > I'm trying to build with cmake (this story is for another mail) a
> > simple example [1] with xenomai 3.0.7. I have some custom macros that
> > basically uses the information from xeno-config.

> > I can build and run the example with the Makefile below in the email.
> > It just works.

> > Narrowing the problem I have obtained the exactly call made by the
> > Makefile created by cmake. It compiles the file using:

> > $ /usr/bin/cc -I/usr/include/xenomai/trank
> > -I/usr/include/xenomai/cobalt -I/usr/include/xenomai
> > -I/usr/include/xenomai/alchemy -D__XENO_COMPAT__ -g -O2
> > -fdebug-prefix-map=/build/xenomai-3.0.7+ds1=. -fstack-protector-strong
> > -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2
> > -fno-omit-frame-pointer -D_GNU_SOURCE -D_REENTRANT
> > -fasynchronous-unwind-tables -D__COBALT__ -o
> > CMakeFiles/rtprint.dir/rtprint.c.o -c
> > /home/leopold.palomo/xenomai/cmake/src/native/rtprint.c


> > and links the file using:

> > $ /usr/bin/cc -Wl,--no-as-needed
> > -Wl,@/usr/lib/x86_64-linux-gnu/modechk.wrappers
> > /usr/lib/x86_64-linux-gnu/xenomai/bootstrap.o -Wl,--wrap=main
> > -Wl,--dynamic-list=/usr/lib/x86_64-linux-gnu/dynlist.ld -Wl,-z,relro
> > -Wl,-z,now -Wl,--as-needed -pthread CMakeFiles/rtprint.dir/rtprint.c.o
> > -o rtprint -rdynamic -ltrank -lalchemy -lcopperplate -lcobalt
> > -lmodechk -lpthread -lrt -lfuse


> > Using the Makefile attached, to compile, make call gcc with:

> > $ make rtprint.o
> > gcc -c -o rtprint.o rtprint.c -I/usr/include/xenomai/trank
> > -D__XENO_COMPAT__ -I/usr/include/xenomai/cobalt -I/usr/include/xenomai
> > -g -O2 -fdebug-prefix-map=/build/xenomai-3.0.7+ds1=.
> > -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
> > -D_FORTIFY_SOURCE=2 -fno-omit-frame-pointer -D_GNU_SOURCE -D_REENTRANT
> > -fasynchronous-unwind-tables -D__COBALT__
> > -I/usr/include/xenomai/alchemy

> > and link with:

> > $ make rtprint
> > gcc -o rtprint rtprint.o -Wl,--no-as-needed -ltrank
> > -Wl,@/usr/lib/x86_64-linux-gnu/modechk.wrappers -lalchemy
> > -lcopperplate /usr/lib/x86_64-linux-gnu/xenomai/bootstrap.o
> > -Wl,--wrap=main
> > -Wl,--dynamic-list=/usr/lib/x86_64-linux-gnu/dynlist.ld
> > -L/usr/lib/x86_64-linux-gnu -lcobalt -lmodechk -lpthread -lrt
> > -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -lfuse -pthread


> > The build result made by CMake is: rtprint (24816 bytes) and rtprint.o
> > (16408 bytes)

> > The build result make using the makefile: rtprint (24720 bytes) and
> > rtprint.o (16312 bytes).

> > If I call the gcc directly I obtain the same bytes. The difference is
> > the stored path. If I strip the executables the size is the same
> > (10224 bytes) but binaries differ.

> > But, and here is the problem. If I run the cmake product I obtain:

> > /rtprint
> > ./rtprint: symbol lookup error:
> > /usr/lib/x86_64-linux-gnu/libcopperplate.so.0: undefined symbol:
> > __real_malloc


> > and the produced with make runs.

> > The produced using cmake has:

> > $ ldd rtprint
> > linux-vdso.so.1 (0x00007ffd0e1e1000)
> > libtrank.so.0 => /usr/lib/x86_64-linux-gnu/libtrank.so.0
> > (0x00007f7b5dec9000)
> > libalchemy.so.0 => /usr/lib/x86_64-linux-gnu/libalchemy.so.0
> > (0x00007f7b5dcb7000)
> > libcopperplate.so.0
> > => /usr/lib/x86_64-linux-gnu/libcopperplate.so.0 (0x00007f7b5da9f000)
> > libcobalt.so.2 => /usr/lib/x86_64-linux-gnu/libcobalt.so.2
> > (0x00007f7b5d87d000)
> > libfuse.so.2 => /lib/x86_64-linux-gnu/libfuse.so.2
> > (0x00007f7b5d63f000) libpthread.so.0
> > => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f7b5d422000)
> > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
> > (0x00007f7b5d083000) /lib64/ld-linux-x86-64.so.2 (0x00007f7b5e2d0000)
> > librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1
> > (0x00007f7b5ce7b000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2
> > (0x00007f7b5cc77000)


> > and with make

> > $ ldd rtprint
> > linux-vdso.so.1 (0x00007ffffcfe2000)
> > libtrank.so.0 => /usr/lib/x86_64-linux-gnu/libtrank.so.0
> > (0x00007f621304f000)
> > libalchemy.so.0 => /usr/lib/x86_64-linux-gnu/libalchemy.so.0
> > (0x00007f6212e3d000)
> > libcopperplate.so.0
> > => /usr/lib/x86_64-linux-gnu/libcopperplate.so.0 (0x00007f6212c25000)
> > libcobalt.so.2 => /usr/lib/x86_64-linux-gnu/libcobalt.so.2
> > (0x00007f6212a03000)
> > libmodechk.so.0 => /usr/lib/x86_64-linux-gnu/libmodechk.so.0
> > (0x00007f6212801000)
> > libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
> > (0x00007f62125e4000)
> > librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1
> > (0x00007f62123dc000) libfuse.so.2
> > => /lib/x86_64-linux-gnu/libfuse.so.2 (0x00007f621219e000) libc.so.6
> > => /lib/x86_64-linux-gnu/libc.so.6
> > (0x00007f6211dff000) /lib64/ld-linux-x86-64.so.2 (0x00007f6213456000)
> > libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6211bfb000)


> > pay attention that first one is not linked against libmodechk,
> > although is specified in the call.


> > I have not found any difference, only the order, so I am really
> > overwhelmed. Any idea?


> > Best regards,


> > Leopold



> > Makefile
> > -------------------------------------------------------------------
> > ###### CONFIGURATION ######

> > ### List of applications to be build
> > APPLICATIONS = rtprint

> > ### Default Xenomai installation path
> > XENO ?= /usr/xenomai

> > XENOCONFIG=$(shell PATH=$(XENO):$(XENO)/bin:$(PATH) which xeno-config
> > 2>/dev/null)

> > CC=$(shell $(XENOCONFIG) --cc)

> > CFLAGS=$(shell $(XENOCONFIG) --skin=native --cflags)

> > LDFLAGS=$(shell $(XENOCONFIG) --skin=native --ldflags)

> > %.o: %.c
> > $(CC) -c -o $@ $< $(CFLAGS)

> > rtprint: rtprint.o
> > $(CC) -o $@ rtprint.o $(LDFLAGS)

> > clean:
> > $(RM) $(APPLICATIONS) *.o

> > all: $(APPLICATIONS)
> > -------------------------------------------------------------------


> > [1]
> > https://gitlab.denx.de/Xenomai/xenomai/blob/eol/v2.6.x/examples/native/rtprint.c




> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai

I also think that this is an interesting question, and not specifically related to cmake. I too build with cmake but I never considered the command line order to be of much importance (in case it compiles).

Isn't he asking: What is the difference between 

gcc -c -o rtprint.o rtprint.c -I/usr/include/xenomai/trank  -D__XENO_COMPAT__ -I/usr/include/xenomai/cobalt -I/usr/include/xenomai  -g -O2 -fdebug-prefix-map=/build/xenomai-3.0.7+ds1=.  -fstack-protector-strong -Wformat 
 -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fno-omit-frame-pointer -D_GNU_SOURCE -D_REENTRANT -fasynchronous-unwind-tables -D__COBALT__ -I/usr/include/xenomai/alchemy  

gcc -o rtprint rtprint.o -Wl,--no-as-needed -ltrank -Wl,@/usr/lib/x86_64-linux-gnu/modechk.wrappers -lalchemy -lcopperplate /usr/lib/x86_64-linux-gnu/xenomai/bootstrap.o -Wl,--wrap=main -Wl,--dynamic-list=/usr/lib/x86_64-linux-gnu/dynlist.ld -L/usr/lib/x86_64-linux-gnu -lcobalt -lmodechk -lpthread -lrt -Wl,-z,relro -Wl,-z,now -Wl,--as-needed   -lfuse -pthread

instead of:

/usr/bin/cc   -I/usr/include/xenomai/trank -I/usr/include/xenomai/cobalt -I/usr/include/xenomai -I/usr/include/xenomai/alchemy  -D__XENO_COMPAT__ -g -O2 -fdebug-prefix-map=/build/xenomai-3.0.7+ds1=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fno-omit-frame-pointer -D_GNU_SOURCE -D_REENTRANT -fasynchronous-unwind-tables -D__COBALT__ -o CMakeFiles/rtprint.dir/rtprint.c.o   -c /home/leopold.palomo/xenomai/cmake/src/native/rtprint.c
 
usr/bin/cc -Wl,--no-as-needed -Wl,@/usr/lib/x86_64-linux-gnu/modechk.wrappers /usr/lib/x86_64-linux-gnu/xenomai/bootstrap.o -Wl,--wrap=main -Wl,--dynamic-list=/usr/lib/x86_64-linux-gnu/dynlist.ld -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -pthread CMakeFiles/rtprint.dir/rtprint.c.o -o rtprint -rdynamic -ltrank -lalchemy -lcopperplate -lcobalt -lmodechk -lpthread -lrt -lfuse  


I can't spot the differences directly because I too am confused by the size of the command.
If it was me, I would try to purify this down to where I get a minimal example that shows the difference, and perhaps then its obvious.

Per Öberg 

Re: [Xenomai] Order options to build a Xenomai program

[Lange Norbert]

Hello,

link order is important and goes left-to-right, this seems to include "wrappers",
which only wrap symbols that where already encountered (to the left of the wrapper argument)

Compare an application using malloc:
Variant A:
<application objects> -Wl,@modechk.wrappers -l modechk

The app is linked, extern symbol malloc is needed.
The call to malloc is wrapped to __wrap_malloc, and __real_malloc would be wrapped to malloc (but __real_malloc is not existing).
The function __wrap_malloc locates and uses the function from libmodechk (which now need malloc in turn).
malloc is used from libc.

Variant B:
-Wl,@modechk.wrappers  <application objects> -l modechk

The call to malloc is wrapped to __wrap_malloc and __real_malloc is wrapped to malloc,
since there is no object file yet, this does nothing.
libmodechk exports __wrap_malloc and __real_malloc, yet no one cares and --as-needed
will remove it as dependency
The app objects depend on malloc.

I am not sure where your dependency to __real_malloc comes from, but I suppose
It's from the bootstrap code, which would be needed to be linked before the wrapper.
Probably weak dependencies further complicate things.

As noted by Henning, please look at https://github.com/nolange/cmake_xenomai,
could use some feedback =).
Particularly look at the patchset which also removes some headaches with linking
precompiled object file for bootstrapping (but needs some upstream changes).

Kind regards,
Norbert

-----Original Message-----
From: Xenomai <xenomai-bounces@xenomai.org> On Behalf Of Leopold Palomo-Avellaneda
Sent: Donnerstag, 6. September 2018 11:53
To: Xenomai@xenomai.org
Subject: [Xenomai] Order options to build a Xenomai program

E-MAIL FROM A NON-ANDRITZ SOURCE: AS A SECURITY MEASURE, PLEASE EXERCISE CAUTION WITH E-MAIL CONTENT AND ANY LINKS OR ATTACHMENTS.


Hi,


I resend this message to the list now that it has again more activity. Maybe some of you cold help me to understand what is wrong here. I'm sorry if it's not appropriate to send again a message to the list.

=====

I have an strange problem and I would like to ask if some clever mind can help me.

I'm trying to build with cmake (this story is for another mail) a simple example [1] with xenomai 3.0.7. I have some custom macros that basically uses the information from xeno-config.

I can build and run the example with the Makefile below in the email. It just works.

Narrowing the problem I have obtained the exactly call made by the Makefile created by cmake. It compiles the file using:

$ /usr/bin/cc   -I/usr/include/xenomai/trank
-I/usr/include/xenomai/cobalt -I/usr/include/xenomai -I/usr/include/xenomai/alchemy  -D__XENO_COMPAT__ -g -O2 -fdebug-prefix-map=/build/xenomai-3.0.7+ds1=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fno-omit-frame-pointer -D_GNU_SOURCE -D_REENTRANT -fasynchronous-unwind-tables -D__COBALT__ -o
CMakeFiles/rtprint.dir/rtprint.c.o   -c
/home/leopold.palomo/xenomai/cmake/src/native/rtprint.c


and links the file using:

$ /usr/bin/cc    -Wl,--no-as-needed
-Wl,@/usr/lib/x86_64-linux-gnu/modechk.wrappers
/usr/lib/x86_64-linux-gnu/xenomai/bootstrap.o -Wl,--wrap=main -Wl,--dynamic-list=/usr/lib/x86_64-linux-gnu/dynlist.ld -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -pthread CMakeFiles/rtprint.dir/rtprint.c.o
-o rtprint -rdynamic -ltrank -lalchemy -lcopperplate -lcobalt -lmodechk -lpthread -lrt -lfuse


Using the Makefile attached, to compile, make call gcc with:

$ make rtprint.o
gcc -c -o rtprint.o rtprint.c -I/usr/include/xenomai/trank -D__XENO_COMPAT__ -I/usr/include/xenomai/cobalt -I/usr/include/xenomai -g -O2 -fdebug-prefix-map=/build/xenomai-3.0.7+ds1=.
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -fno-omit-frame-pointer -D_GNU_SOURCE -D_REENTRANT -fasynchronous-unwind-tables -D__COBALT__ -I/usr/include/xenomai/alchemy

and link with:

$ make rtprint
gcc -o rtprint rtprint.o -Wl,--no-as-needed -ltrank -Wl,@/usr/lib/x86_64-linux-gnu/modechk.wrappers -lalchemy -lcopperplate /usr/lib/x86_64-linux-gnu/xenomai/bootstrap.o -Wl,--wrap=main -Wl,--dynamic-list=/usr/lib/x86_64-linux-gnu/dynlist.ld
-L/usr/lib/x86_64-linux-gnu -lcobalt -lmodechk -lpthread -lrt
-Wl,-z,relro -Wl,-z,now -Wl,--as-needed   -lfuse -pthread


The build result made by CMake is: rtprint (24816 bytes) and rtprint.o
(16408 bytes)

The build result make using the makefile: rtprint (24720 bytes) and rtprint.o (16312 bytes).

If I call the gcc directly I obtain the same bytes. The difference is the stored path. If I strip the executables the size is the same (10224
bytes) but binaries differ.

But, and here is the problem. If I run the cmake product I obtain:

/rtprint
./rtprint: symbol lookup error:
/usr/lib/x86_64-linux-gnu/libcopperplate.so.0: undefined symbol:
__real_malloc


and the produced with make runs.

The produced using cmake has:

$ ldd rtprint
        linux-vdso.so.1 (0x00007ffd0e1e1000)
        libtrank.so.0 => /usr/lib/x86_64-linux-gnu/libtrank.so.0
(0x00007f7b5dec9000)
        libalchemy.so.0 => /usr/lib/x86_64-linux-gnu/libalchemy.so.0
(0x00007f7b5dcb7000)
        libcopperplate.so.0 => /usr/lib/x86_64-linux-gnu/libcopperplate.so.0
(0x00007f7b5da9f000)
        libcobalt.so.2 => /usr/lib/x86_64-linux-gnu/libcobalt.so.2
(0x00007f7b5d87d000)
        libfuse.so.2 => /lib/x86_64-linux-gnu/libfuse.so.2 (0x00007f7b5d63f000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007f7b5d422000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7b5d083000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f7b5e2d0000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f7b5ce7b000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f7b5cc77000)


and with make

$ ldd rtprint
        linux-vdso.so.1 (0x00007ffffcfe2000)
        libtrank.so.0 => /usr/lib/x86_64-linux-gnu/libtrank.so.0
(0x00007f621304f000)
        libalchemy.so.0 => /usr/lib/x86_64-linux-gnu/libalchemy.so.0
(0x00007f6212e3d000)
        libcopperplate.so.0 => /usr/lib/x86_64-linux-gnu/libcopperplate.so.0
(0x00007f6212c25000)
        libcobalt.so.2 => /usr/lib/x86_64-linux-gnu/libcobalt.so.2
(0x00007f6212a03000)
        libmodechk.so.0 => /usr/lib/x86_64-linux-gnu/libmodechk.so.0
(0x00007f6212801000)
        libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007f62125e4000)
        librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f62123dc000)
        libfuse.so.2 => /lib/x86_64-linux-gnu/libfuse.so.2 (0x00007f621219e000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6211dff000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f6213456000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6211bfb000)


pay attention that first one is not linked against libmodechk, although is specified in the call.


I have not found any difference, only the order, so I am really overwhelmed. Any idea?


Best regards,


Leopold



Makefile
-------------------------------------------------------------------
###### CONFIGURATION ######

### List of applications to be build
APPLICATIONS = rtprint

### Default Xenomai installation path
XENO ?= /usr/xenomai

XENOCONFIG=$(shell PATH=$(XENO):$(XENO)/bin:$(PATH) which xeno-config
2>/dev/null)

CC=$(shell $(XENOCONFIG) --cc)

CFLAGS=$(shell $(XENOCONFIG) --skin=native --cflags)

LDFLAGS=$(shell $(XENOCONFIG) --skin=native --ldflags)

%.o: %.c
        $(CC) -c -o $@ $< $(CFLAGS)

rtprint: rtprint.o
        $(CC) -o $@ rtprint.o $(LDFLAGS)

clean:
        $(RM) $(APPLICATIONS) *.o

all: $(APPLICATIONS)
-------------------------------------------------------------------


[1]
https://gitlab.denx.de/Xenomai/xenomai/blob/eol/v2.6.x/examples/native/rtprint.c



--
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

_______________________________________________
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai
________________________________

This message and any attachments are solely for the use of the intended recipients. They may contain privileged and/or confidential information or other information protected from disclosure. If you are not an intended recipient, you are hereby notified that you received this email in error and that any review, dissemination, distribution or copying of this email and any attachment is strictly prohibited. If you have received this email in error, please contact the sender and delete the message and any attachment from your system.

ANDRITZ HYDRO GmbH


Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You
________________________________

Re: [Xenomai] Order options to build a Xenomai program

[Leopold Palomo-Avellaneda]

Hi,

El 13/09/18 a les 14:42, Lange Norbert ha escrit:

> link order is important and goes left-to-right, this seems to include "wrappers",
> which only wrap symbols that where already encountered (to the left of the wrapper argument)

[...]


> The call to malloc is wrapped to __wrap_malloc and __real_malloc is wrapped to malloc,
> since there is no object file yet, this does nothing.
> libmodechk exports __wrap_malloc and __real_malloc, yet no one cares and --as-needed
> will remove it as dependency
> The app objects depend on malloc.
> 
> I am not sure where your dependency to __real_malloc comes from, but I suppose
> It's from the bootstrap code, which would be needed to be linked before the wrapper.
> Probably weak dependencies further complicate things.

I think that you got the point!!

So, from my point of view it confirm my suspicious that the wrapper
mechanism is fragile. I really didn't understand why Xenomai core team
changed the native API for the POSIX. Although I saw the Jan Kiska
conference video explaining it, tell me primitive or dump, but I prefer
to have a RT API that links against RT libraries and you can mix the
POSIX functions that you want in a clear way.

OTOH I have to admit that convert a POSIX program to RT in an easy way
is amazing.

> As noted by Henning, please look at https://github.com/nolange/cmake_xenomai,
> could use some feedback =).
> Particularly look at the patchset which also removes some headaches with linking
> precompiled object file for bootstrapping (but needs some upstream changes).

Norbert, I have followed your emails and your project. You did a good
job, but I don't agree with your approach. My points are:

- You are trying to convert Xenomai a CMake project and this probably
will not happen because Upstream is very happy with the autotools. I
don't like to touch anything from upstream. Maybe some patch, but
incorporated in Upstream.

- I would prefer follow the Upstream guidelines that recommends use
xeno-config to obtain the needed parameters to build your application.
So, any build tool should use xeno-config (maintained by upstream) that
provide the correct flags or whatever to build your application.

- I agree with Norbert that bootstraped code is not a good idea. But
this change should be done by upstream. But if I'm not wrong, Phillipe
said that it hasn't an easy solution.

But for the curious, I have done this example:

https://github.com/iocroblab/xenomai-cmake

but it's not polished and had some mistakes. The idea is to use any
Xenomai installation without touched and then use CMake to build your
application.

Cheers,

Leopold


-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Re: [Xenomai] Order options to build a Xenomai program

[Per Oberg]

----- Den 13 sep 2018, på kl 23:36, Leopold Palomo-Avellaneda leo@alaxarxa.net skrev:

> Hi,

> El 13/09/18 a les 14:42, Lange Norbert ha escrit:

>> link order is important and goes left-to-right, this seems to include
> > "wrappers",
>> which only wrap symbols that where already encountered (to the left of the
> > wrapper argument)

> [...]

>> The call to malloc is wrapped to __wrap_malloc and __real_malloc is wrapped to
> > malloc,
> > since there is no object file yet, this does nothing.
>> libmodechk exports __wrap_malloc and __real_malloc, yet no one cares and
> > --as-needed
> > will remove it as dependency
> > The app objects depend on malloc.

> > I am not sure where your dependency to __real_malloc comes from, but I suppose
>> It's from the bootstrap code, which would be needed to be linked before the
> > wrapper.
> > Probably weak dependencies further complicate things.

> I think that you got the point!!

> So, from my point of view it confirm my suspicious that the wrapper
> mechanism is fragile. I really didn't understand why Xenomai core team
> changed the native API for the POSIX. Although I saw the Jan Kiska
> conference video explaining it, tell me primitive or dump, but I prefer
> to have a RT API that links against RT libraries and you can mix the
> POSIX functions that you want in a clear way.

> OTOH I have to admit that convert a POSIX program to RT in an easy way
> is amazing.


This! 

Being able to use the same code, without patches or a lot of defines including other files is a very clean way of debugging your software. I often set up Simulations where I use my laptop running or our controller, possibly connected to remote hardware to debug stuff. For these cases  the POSIX skin is very useful.

> > As noted by Henning, please look at https://github.com/nolange/cmake_xenomai,
> > could use some feedback =).
> > Particularly look at the patchset which also removes some headaches with linking
> > precompiled object file for bootstrapping (but needs some upstream changes).

> Norbert, I have followed your emails and your project. You did a good
> job, but I don't agree with your approach. My points are:

> - You are trying to convert Xenomai a CMake project and this probably
> will not happen because Upstream is very happy with the autotools. I
> don't like to touch anything from upstream. Maybe some patch, but
> incorporated in Upstream.

What do you mean with "convert Xenomai a CMake project"? I feel that I am missing something...

Is it simply that  the "xeno-config" way of doing things isn't cmak-onic enough for a "real" CMake project or is there something deeper?

> - I would prefer follow the Upstream guidelines that recommends use
> xeno-config to obtain the needed parameters to build your application.
> So, any build tool should use xeno-config (maintained by upstream) that
> provide the correct flags or whatever to build your application.

> - I agree with Norbert that bootstraped code is not a good idea. But
> this change should be done by upstream. But if I'm not wrong, Phillipe
> said that it hasn't an easy solution.

> But for the curious, I have done this example:

> https://github.com/iocroblab/xenomai-cmake

> but it's not polished and had some mistakes. The idea is to use any
> Xenomai installation without touched and then use CMake to build your
> application.

> Cheers,

> Leopold

> --
> --
> Linux User 152692 GPG: 05F4A7A949A2D9AA
> Catalonia
> -------------------------------------
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing in e-mail?

> _______________________________________________
> Xenomai mailing list
> Xenomai@xenomai.org
> https://xenomai.org/mailman/listinfo/xenomai

Thanks,
Per Öberg 

Re: [Xenomai] Order options to build a Xenomai program

[Julien Blanc]

Le vendredi 14 septembre 2018 à 02:45 -0500, Per Oberg a écrit :
> 
> This! 
> 
> Being able to use the same code, without patches or a lot of defines
> including other files is a very clean way of debugging your software.
> I often set up Simulations where I use my laptop running or our
> controller, possibly connected to remote hardware to debug stuff. For
> these cases  the POSIX skin is very useful.

I thought that was the purpose of the mercury core.

For a full xenomai application, the wrapping mechanism is nice. For a
mixed rt / non-rt executable, this tends to be full of pitfalls. The
__RT and __STD macros are of a great help in this regard. 

I also still wonder if there’s a way to make std::thread work in such a
mixed environment.

> What do you mean with "convert Xenomai a CMake project"? I feel that
> I am missing something...

I think it means "build xenomai with cmake" (which is unlikely to
happen afaik).

Regards,

Julien

Re: [Xenomai] Order options to build a Xenomai program

[Lange Norbert]

> So, from my point of view it confirm my suspicious that the wrapper
> mechanism is fragile. I really didn't understand why Xenomai core team
> changed the native API for the POSIX. Although I saw the Jan Kiska
> conference video explaining it, tell me primitive or dump, but I prefer to have
> a RT API that links against RT libraries and you can mix the POSIX functions
> that you want in a clear way.
>
> OTOH I have to admit that convert a POSIX program to RT in an easy way is
> amazing.

You can explicitly use the cobalt or std function with macros.
That said I have my issues with cascading headers from linux, c library and cobalt,
this is hard to follow with symbols potentially coming from anywhere.

> Norbert, I have followed your emails and your project. You did a good job,
> but I don't agree with your approach. My points are:
>
> - You are trying to convert Xenomai a CMake project and this probably will
> not happen because Upstream is very happy with the autotools. I don't like
> to touch anything from upstream. Maybe some patch, but incorporated in
> Upstream.

Sorry, that's nonsense, never thought about building Xenomai with CMake.

> - I would prefer follow the Upstream guidelines that recommends use xeno-
> config to obtain the needed parameters to build your application.
> So, any build tool should use xeno-config (maintained by upstream) that
> provide the correct flags or whatever to build your application.

I tried multiple approaches, using xeno-config fell out shortly.
-   it's (logically) an target "executable".
    That imposes problems with CMake's normal search for those,
    not to mention CI when your builder works in a partition with noexec.
    I would want to use config-files directly or with a host-executable,
    like pkg-config uses .pc files.
-   has problems if you relocate your build environment
    I would prefer relative paths for simplicity
-   I need to extract all information and not just flags for ONE configuration
    That’s the most important issue, I need the "building blocks" of the command
    line, not ONE commandline. This means you need to know xeno-config
    and its flags precisely and figure out how to dissect multiple outputs
    in those "building blocks".
    Fragile and not forwards-compatible.

Whats left is two variants:

FindXenomai - this would be placed in your project or up streamed in CMake.
Uses CMake functions to guess the paths, this might be hard to do with some libdir / includedir
Configurations and would need to be updated independently of Xenomai.

CMake Config files - you place those in <libpath>/cmake/xenomai.
Those can be generated by config/install_cmakeconfig.sh from the repo (use same arguments as when configuring CMake).
The previously mentioned patchset adds those files to Xenomai and does this automatically when installing (using the autotools system).
Upstreaming in Xenomai would make everything hassle-free and forwards-compatible (the config files would always match the version).

The downside is of course that this would then be a burden to the Xenomai devs, but it should not need any changes outside of structural changes.
At which point someone will have to adapt CMake integration, however its done - I would prefer it to be done just once


The repo contains other changes, attempting to sanitize the bootstrapping methods,
Without those the provided examples might not work (only the upstream bootstrapping method will work).
I hope atleast those can be upstreamed.

> - I agree with Norbert that bootstraped code is not a good idea. But this
> change should be done by upstream. But if I'm not wrong, Phillipe said that it
> hasn't an easy solution.

It has no easy solution if you want to do build a POSIX-only project purely with linker arguments.
When you can afford add some lines of (Xenomai-specific) code to your project, it opens a lot possibilities.

>
> But for the curious, I have done this example:
>
> https://github.com/iocroblab/xenomai-cmake
>
> but it's not polished and had some mistakes. The idea is to use any Xenomai
> installation without touched and then use CMake to build your application.

Yes I get that, and I tried the same with FindXenomai. I consider the CMake Config approach
a lot better.

Norbert
________________________________

This message and any attachments are solely for the use of the intended recipients. They may contain privileged and/or confidential information or other information protected from disclosure. If you are not an intended recipient, you are hereby notified that you received this email in error and that any review, dissemination, distribution or copying of this email and any attachment is strictly prohibited. If you have received this email in error, please contact the sender and delete the message and any attachment from your system.

ANDRITZ HYDRO GmbH


Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You
________________________________

Re: [Xenomai] Order options to build a Xenomai program

[Giulio Moro]

> So, from my point of view it confirm my suspicious that the wrapper
> mechanism is fragile. I really didn't understand why Xenomai core team
> changed the native API for the POSIX. Although I saw the Jan Kiska
> conference video explaining it, tell me primitive or dump, but I prefer to have
> a RT API that links against RT libraries and you can mix the POSIX functions
> that you want in a clear way.
>
> OTOH I have to admit that convert a POSIX program to RT in an easy way is
> amazing.

I normally disable wrappers and call explicitly the `__wrap_` equivalent when I want to use a Xenomai function , that is for instance `__wrap_pthread_create()` instead of `pthread_create()`.
I also add my own forward declaration, e.g.:

int __wrap_pthread_create(pthread_t *thread, const pthread_attr_t *attr, void *(*start_routine) (void *), void *arg);

But maybe this is already provided in some of the Cobalt headers.

Re: [Xenomai] Order options to build a Xenomai program

[Leopold Palomo-Avellaneda]

On 14/09/18 09:45, Per Oberg wrote:

[...]

> 
> Being able to use the same code, without patches or a lot of defines including other files is a very clean way of debugging your software. I often set up Simulations where I use my laptop running or our controller, possibly connected to remote hardware to debug stuff. For these cases  the POSIX skin is very useful.
> 
>>> As noted by Henning, please look at https://github.com/nolange/cmake_xenomai,
>>> could use some feedback =).
>>> Particularly look at the patchset which also removes some headaches with linking
>>> precompiled object file for bootstrapping (but needs some upstream changes).
> 
>> Norbert, I have followed your emails and your project. You did a good
>> job, but I don't agree with your approach. My points are:
> 
>> - You are trying to convert Xenomai a CMake project and this probably
>> will not happen because Upstream is very happy with the autotools. I
>> don't like to touch anything from upstream. Maybe some patch, but
>> incorporated in Upstream.
> 
> What do you mean with "convert Xenomai a CMake project"? I feel that I am missing something...
> Is it simply that  the "xeno-config" way of doing things isn't cmak-onic enough for a "real" CMake project or is there something deeper?

well, I'm sorry I have been not clear. I'm saying the Norbert is trying to
generate the config files that normally are generating by cmake.

Leopold
-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Re: [Xenomai] Order options to build a Xenomai program

[Leopold Palomo-Avellaneda]

On 14/09/18 11:14, Lange Norbert wrote:
>> So, from my point of view it confirm my suspicious that the wrapper
>> mechanism is fragile. I really didn't understand why Xenomai core team
>> changed the native API for the POSIX. Although I saw the Jan Kiska
>> conference video explaining it, tell me primitive or dump, but I prefer to have
>> a RT API that links against RT libraries and you can mix the POSIX functions
>> that you want in a clear way.
>>
>> OTOH I have to admit that convert a POSIX program to RT in an easy way is
>> amazing.
> 
> You can explicitly use the cobalt or std function with macros.
> That said I have my issues with cascading headers from linux, c library and cobalt,
> this is hard to follow with symbols potentially coming from anywhere.

right

>> Norbert, I have followed your emails and your project. You did a good job,
>> but I don't agree with your approach. My points are:
>>
>> - You are trying to convert Xenomai a CMake project and this probably will
>> not happen because Upstream is very happy with the autotools. I don't like
>> to touch anything from upstream. Maybe some patch, but incorporated in
>> Upstream.
> 
> Sorry, that's nonsense, never thought about building Xenomai with CMake.

Sorry, you are right. It seemed that you tried to generated the config files
generated usually with a cmake project.


>> - I would prefer follow the Upstream guidelines that recommends use xeno-
>> config to obtain the needed parameters to build your application.
>> So, any build tool should use xeno-config (maintained by upstream) that
>> provide the correct flags or whatever to build your application.
> 
> I tried multiple approaches, using xeno-config fell out shortly.
> -   it's (logically) an target "executable".
>     That imposes problems with CMake's normal search for those,
>     not to mention CI when your builder works in a partition with noexec.
>     I would want to use config-files directly or with a host-executable,
>     like pkg-config uses .pc files.

I have not found any important problem with the xeno-config generate info or any
problem with cmake. I agree with you that you need to exec an script to generate
the info and it could have problems with partitions with noexec, etc.

[...]

> -   I need to extract all information and not just flags for ONE configuration

I don't extract the information for one configuration. I extract ALL the modules
installed.

>     That’s the most important issue, I need the "building blocks" of the command
>     line, not ONE commandline. This means you need to know xeno-config
>     and its flags precisely and figure out how to dissect multiple outputs
>     in those "building blocks".
>     Fragile and not forwards-compatible.

I don't agree. xeno-config is quite stable and well maintained. And it give you
the information that Upstream want that YOU use.

> Whats left is two variants:
> 
> FindXenomai - this would be placed in your project or up streamed in CMake.
> Uses CMake functions to guess the paths, this might be hard to do with some libdir / includedir
> Configurations and would need to be updated independently of Xenomai.

this is one way. Currently it just works.


> CMake Config files - you place those in <libpath>/cmake/xenomai.
> Those can be generated by config/install_cmakeconfig.sh from the repo (use same arguments as when configuring CMake).
> The previously mentioned patchset adds those files to Xenomai and does this automatically when installing (using the autotools system).
> Upstreaming in Xenomai would make everything hassle-free and forwards-compatible (the config files would always match the version).
> 
> The downside is of course that this would then be a burden to the Xenomai devs, but it should not need any changes outside of structural changes.
> At which point someone will have to adapt CMake integration, however its done - I would prefer it to be done just once
> 
> 
> The repo contains other changes, attempting to sanitize the bootstrapping methods,
> Without those the provided examples might not work (only the upstream bootstrapping method will work).
> I hope atleast those can be upstreamed.

So, maybe that config files generated by the autotools, are to me the best
solution. Then, the responsible of compile and install xenomai in a system
will generate the config files to use it.

But for this solution you need that Jan or Phillipe accept that and maintain
that. And looking your code and I would prefer a more simple way without modules
and simple, just fill some config vars. Because then it could be easy to maintain.


>> - I agree with Norbert that bootstraped code is not a good idea. But this
>> change should be done by upstream. But if I'm not wrong, Phillipe said that it
>> hasn't an easy solution.
> 
> It has no easy solution if you want to do build a POSIX-only project purely with linker arguments.
> When you can afford add some lines of (Xenomai-specific) code to your project, it opens a lot possibilities.
> 
>>
>> But for the curious, I have done this example:
>>
>> https://github.com/iocroblab/xenomai-cmake
>>
>> but it's not polished and had some mistakes. The idea is to use any Xenomai
>> installation without touched and then use CMake to build your application.
> 
> Yes I get that, and I tried the same with FindXenomai. I consider the CMake Config approach
> a lot better.

:-)

Cheers,

Leopold



-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://xenomai.org/pipermail/xenomai/attachments/20180914/b038baff/attachment.sig>

Re: [Xenomai] Order options to build a Xenomai program

[Lange Norbert]

>>> Norbert, I have followed your emails and your project. You did a good job,
>>> but I don't agree with your approach. My points are:
>>>
>>> - You are trying to convert Xenomai a CMake project and this probably will
>>> not happen because Upstream is very happy with the autotools. I don't like
>>> to touch anything from upstream. Maybe some patch, but incorporated in
>>> Upstream.
>>
>> Sorry, that's nonsense, never thought about building Xenomai with CMake.

> Sorry, you are right. It seemed that you tried to generated the config files
> generated usually with a cmake project.

I do, but that's not happening during configuration or installation. I created
the config templates with CMake as thast alot less error-prone and easier to maintain

>>> - I would prefer follow the Upstream guidelines that recommends use xeno-
>>> config to obtain the needed parameters to build your application.
>>> So, any build tool should use xeno-config (maintained by upstream) that
>>> provide the correct flags or whatever to build your application.
>>
>> I tried multiple approaches, using xeno-config fell out shortly.
>> -   it's (logically) an target "executable".
>>     That imposes problems with CMake's normal search for those,
>>     not to mention CI when your builder works in a partition with noexec.
>>     I would want to use config-files directly or with a host-executable,
>>     like pkg-config uses .pc files.
>
> I have not found any important problem with the xeno-config generate info or any
> problem with cmake. I agree with you that you need to exec an script to generate
> the info and it could have problems with partitions with noexec, etc.

Well, I did find problems if you eg. create a "buildroot" and then move it.

>> -   I need to extract all information and not just flags for ONE configuration
>
> I don't extract the information for one configuration. I extract ALL the modules
> installed.

yes, and xeno-config was not conceived for that.

>>     That’s the most important issue, I need the "building blocks" of the command
>>     line, not ONE commandline. This means you need to know xeno-config
>>     and its flags precisely and figure out how to dissect multiple outputs
>>     in those "building blocks".
>>     Fragile and not forwards-compatible.
>
> I don't agree. xeno-config is quite stable and well maintained. And it give you
> the information that Upstream want that YOU use.

figuring out the arguments and parsing them from within CMake is what I meant with fragile
and not forwards-compatible.
If you have a project with Xenomai3 and a FindXenomai script,
then you might have to update your code just to be able to use a future
version. like for example if the linking order changed, which I suppose you aren't
deducing but use a fixed order.

>> Whats left is two variants:
>>
>> FindXenomai - this would be placed in your project or up streamed in CMake.
>> Uses CMake functions to guess the paths, this might be hard to do with some libdir / includedir
>> Configurations and would need to be updated independently of Xenomai.
>
> this is one way. Currently it just works.

It works for a couple projects you are using.

>> CMake Config files - you place those in <libpath>/cmake/xenomai.
>> Those can be generated by config/install_cmakeconfig.sh from the repo (use same arguments as when configuring CMake).
>> The previously mentioned patchset adds those files to Xenomai and does this automatically when installing (using the autotools system).
>> Upstreaming in Xenomai would make everything hassle-free and forwards-compatible (the config files would always match the version).
>>
>> The downside is of course that this would then be a burden to the Xenomai devs, but it should not need any changes outside of structural changes.
>> At which point someone will have to adapt CMake integration, however its done - I would prefer it to be done just once
>>
>>
>> The repo contains other changes, attempting to sanitize the bootstrapping methods,
>> Without those the provided examples might not work (only the upstream bootstrapping method will work).
>> I hope atleast those can be upstreamed.
>
> So, maybe that config files generated by the autotools, are to me the best
> solution. Then, the responsible of compile and install xenomai in a system
> will generate the config files to use it.

the config files are not generated from scratch but have placeholders,
the same placeholders xeno-config has. That's using the information
right from the source =)

> But for this solution you need that Jan or Phillipe accept that and maintain
> that.

Yep. I have to start somewhere though.

> And looking your code and I would prefer a more simple way without modules
> and simple, just fill some config vars. Because then it could be easy to maintain.

The repo deals with multiple issues, the config stuff is rather simple and straightforward.
not sure what you mean with modules? if you mean you prefer using CMake variables
instead of imported libraries - sorry that's pretty much *the* CMake antipattern.
(To many reasons to list, just google for "modern CMake").

*Using* Xenomai is as hard as adding this:

find_package(Xenomai REQUIRED)

xenomai_target_bootstrap(default_exe
        SKINS posix
)

Norbert
________________________________

This message and any attachments are solely for the use of the intended recipients. They may contain privileged and/or confidential information or other information protected from disclosure. If you are not an intended recipient, you are hereby notified that you received this email in error and that any review, dissemination, distribution or copying of this email and any attachment is strictly prohibited. If you have received this email in error, please contact the sender and delete the message and any attachment from your system.

ANDRITZ HYDRO GmbH


Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You
________________________________