* [Xenomai] Order options to build a Xenomai program @ 2018-09-06 9:52 Leopold Palomo-Avellaneda 2018-09-13 8:54 ` Henning Schild 2018-09-13 12:42 ` Lange Norbert 0 siblings, 2 replies; 12+ messages in thread From: Leopold Palomo-Avellaneda @ 2018-09-06 9:52 UTC (permalink / raw) To: Xenomai@xenomai.org 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? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Xenomai] Order options to build a Xenomai program 2018-09-06 9:52 [Xenomai] Order options to build a Xenomai program Leopold Palomo-Avellaneda @ 2018-09-13 8:54 ` Henning Schild 2018-09-13 9:17 ` Per Oberg 2018-09-13 12:42 ` Lange Norbert 1 sibling, 1 reply; 12+ messages in thread From: Henning Schild @ 2018-09-13 8:54 UTC (permalink / raw) To: Leopold Palomo-Avellaneda; +Cc: Xenomai@xenomai.org, Lange Norbert 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 > > > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Xenomai] Order options to build a Xenomai program 2018-09-13 8:54 ` Henning Schild @ 2018-09-13 9:17 ` Per Oberg 0 siblings, 0 replies; 12+ messages in thread From: Per Oberg @ 2018-09-13 9:17 UTC (permalink / raw) To: xenomai ----- 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Xenomai] Order options to build a Xenomai program 2018-09-06 9:52 [Xenomai] Order options to build a Xenomai program Leopold Palomo-Avellaneda 2018-09-13 8:54 ` Henning Schild @ 2018-09-13 12:42 ` Lange Norbert 2018-09-13 21:36 ` Leopold Palomo-Avellaneda 1 sibling, 1 reply; 12+ messages in thread From: Lange Norbert @ 2018-09-13 12:42 UTC (permalink / raw) To: Leopold Palomo-Avellaneda, Xenomai@xenomai.org 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 ________________________________ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Xenomai] Order options to build a Xenomai program 2018-09-13 12:42 ` Lange Norbert @ 2018-09-13 21:36 ` Leopold Palomo-Avellaneda 2018-09-14 7:45 ` Per Oberg 2018-09-14 9:14 ` Lange Norbert 0 siblings, 2 replies; 12+ messages in thread From: Leopold Palomo-Avellaneda @ 2018-09-13 21:36 UTC (permalink / raw) To: Lange Norbert, Xenomai@xenomai.org 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? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Xenomai] Order options to build a Xenomai program 2018-09-13 21:36 ` Leopold Palomo-Avellaneda @ 2018-09-14 7:45 ` Per Oberg 2018-09-14 8:22 ` Julien Blanc 2018-09-14 13:54 ` Leopold Palomo-Avellaneda 2018-09-14 9:14 ` Lange Norbert 1 sibling, 2 replies; 12+ messages in thread From: Per Oberg @ 2018-09-14 7:45 UTC (permalink / raw) To: xenomai ----- 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Xenomai] Order options to build a Xenomai program 2018-09-14 7:45 ` Per Oberg @ 2018-09-14 8:22 ` Julien Blanc 2018-09-14 13:54 ` Leopold Palomo-Avellaneda 1 sibling, 0 replies; 12+ messages in thread From: Julien Blanc @ 2018-09-14 8:22 UTC (permalink / raw) To: Per Oberg, xenomai 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Xenomai] Order options to build a Xenomai program 2018-09-14 7:45 ` Per Oberg 2018-09-14 8:22 ` Julien Blanc @ 2018-09-14 13:54 ` Leopold Palomo-Avellaneda 1 sibling, 0 replies; 12+ messages in thread From: Leopold Palomo-Avellaneda @ 2018-09-14 13:54 UTC (permalink / raw) To: Per Oberg, xenomai 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? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Xenomai] Order options to build a Xenomai program 2018-09-13 21:36 ` Leopold Palomo-Avellaneda 2018-09-14 7:45 ` Per Oberg @ 2018-09-14 9:14 ` Lange Norbert 2018-09-14 12:19 ` Giulio Moro 2018-09-14 14:16 ` Leopold Palomo-Avellaneda 1 sibling, 2 replies; 12+ messages in thread From: Lange Norbert @ 2018-09-14 9:14 UTC (permalink / raw) To: Leopold Palomo-Avellaneda, Xenomai@xenomai.org > 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 ________________________________ ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Xenomai] Order options to build a Xenomai program 2018-09-14 9:14 ` Lange Norbert @ 2018-09-14 12:19 ` Giulio Moro 2018-09-14 14:16 ` Leopold Palomo-Avellaneda 1 sibling, 0 replies; 12+ messages in thread From: Giulio Moro @ 2018-09-14 12:19 UTC (permalink / raw) To: Lange Norbert, Leopold Palomo-Avellaneda, Xenomai@xenomai.org > 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Xenomai] Order options to build a Xenomai program 2018-09-14 9:14 ` Lange Norbert 2018-09-14 12:19 ` Giulio Moro @ 2018-09-14 14:16 ` Leopold Palomo-Avellaneda 2018-09-14 16:03 ` Lange Norbert 1 sibling, 1 reply; 12+ messages in thread From: Leopold Palomo-Avellaneda @ 2018-09-14 14:16 UTC (permalink / raw) To: Lange Norbert, Xenomai@xenomai.org 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> ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [Xenomai] Order options to build a Xenomai program 2018-09-14 14:16 ` Leopold Palomo-Avellaneda @ 2018-09-14 16:03 ` Lange Norbert 0 siblings, 0 replies; 12+ messages in thread From: Lange Norbert @ 2018-09-14 16:03 UTC (permalink / raw) To: Leopold Palomo-Avellaneda, Xenomai@xenomai.org >>> 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 ________________________________ ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2018-09-14 16:03 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-09-06 9:52 [Xenomai] Order options to build a Xenomai program Leopold Palomo-Avellaneda 2018-09-13 8:54 ` Henning Schild 2018-09-13 9:17 ` Per Oberg 2018-09-13 12:42 ` Lange Norbert 2018-09-13 21:36 ` Leopold Palomo-Avellaneda 2018-09-14 7:45 ` Per Oberg 2018-09-14 8:22 ` Julien Blanc 2018-09-14 13:54 ` Leopold Palomo-Avellaneda 2018-09-14 9:14 ` Lange Norbert 2018-09-14 12:19 ` Giulio Moro 2018-09-14 14:16 ` Leopold Palomo-Avellaneda 2018-09-14 16:03 ` Lange Norbert
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.