[Xenomai] Build order options

Leopold Palomo-Avellaneda leo at alaxarxa.net
Tue Jul 24 17:11:59 CEST 2018


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

and links the file using:

$ /usr/bin/cc    -Wl,--no-as-needed
/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
-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: symbol lookup error:
/usr/lib/x86_64-linux-gnu/libcopperplate.so.0: undefined symbol:

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
	libalchemy.so.0 => /usr/lib/x86_64-linux-gnu/libalchemy.so.0
	libcopperplate.so.0 => /usr/lib/x86_64-linux-gnu/libcopperplate.so.0
	libcobalt.so.2 => /usr/lib/x86_64-linux-gnu/libcobalt.so.2
	libfuse.so.2 => /lib/x86_64-linux-gnu/libfuse.so.2 (0x00007f7b5d63f000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
	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
	libalchemy.so.0 => /usr/lib/x86_64-linux-gnu/libalchemy.so.0
	libcopperplate.so.0 => /usr/lib/x86_64-linux-gnu/libcopperplate.so.0
	libcobalt.so.2 => /usr/lib/x86_64-linux-gnu/libcobalt.so.2
	libmodechk.so.0 => /usr/lib/x86_64-linux-gnu/libmodechk.so.0
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
	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,


###### CONFIGURATION ######

### List of applications to be build

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

XENOCONFIG=$(shell PATH=$(XENO):$(XENO)/bin:$(PATH) which xeno-config

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)




Linux User 152692     GPG: 05F4A7A949A2D9AA
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/20180724/c02f0b10/attachment.sig>

More information about the Xenomai mailing list