Hi,
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?
-------------- 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>
_______________________________________________
Xenomai mailing list
Xenomai@xenomai.org
https://xenomai.org/mailman/listinfo/xenomai
