Opened 6 years ago

Closed 6 years ago

#1186 closed defect/bug (fixed)

cmake build incomplete when use SHARED_LIBNAVIT

Reported by: tuxmaster Owned by: sleske
Priority: minor Milestone: version 0.5.1
Component: core Version: git master
Severity: normal Keywords: cmake, build, libs
Cc: sebastian.leske@…

Description (last modified by usul)

Hello, when build navit with:

cmake -DSAMPLE_MAP=false -DSHARED_LIBNAVIT=true

and run "make install" after build, the following libs are missing:

  • libfib.so
  • libnavit_core.so
  • libmaptool_core.so

They are linked again maptool and navit but not installed. SVN Version: 5725

Change History (9)

comment:1 Changed 6 years ago by usul

  • Description modified (diff)
  • Keywords cmake build libs added
  • Milestone set to version 0.5.1

comment:2 Changed 6 years ago by sleske

  • Owner changed from KaZeR to sleske
  • Priority changed from major to minor
  • Status changed from new to assigned

I cannot replicate this as described. If I build as describe above, I only get libnavit_core.so, but no libfib.so or libmaptool_core.so

I checked the CMake setup and could not find any way to generate libfib.so or libmaptool_core.so. From what I see, the CMakeLists.txt in navit/fib-1.1/ and navit/maptool/ are hardcoded to generate shared libraries. Or did you maybe set CMake variable BUILD_SHARED_LIBS? Then dont' do that...

As far as libnavit_core.so goes, you are right: With -DSHARED_LIBNAVIT=true navit and maptool need to link against libnavit_core.so, but it is not installed.

However, as far as I can see the SHARED_LIBNAVIT switch is only meant for the Android builds. So, could you explain why you want to build a shared libnavit_core.so? Otherwise, I'll just remove the SHARED_LIBNAVIT switch from the build (except for Android builds) and close this bug.

comment:3 Changed 6 years ago by sleske

Also, please indicate your build environment (OS and CMake version).

comment:4 follow-up: Changed 6 years ago by tuxmaster

Hello, see #1195 for the complete build log, because it will be the same build procedure.

comment:5 in reply to: ↑ 4 Changed 6 years ago by sleske

Replying to http://wiki.navit-project.org/index.php/user:tuxmaster:

Hello, see #1195 for the complete build log

Thanks. I can see you are calling CMake with -DSHARED_LIBNAVIT=true (and loads of other variables.

But the question still remains: Why are you doing this? Don't manually set variables if unless you know what they do, which you clearly do not :-).

comment:6 follow-up: Changed 6 years ago by tuxmaster

The idea behind was, that the maptool and the navit program will get smaller, because navit self and maptool use lot code together.

ldd /usr/bin/maptool
	linux-vdso.so.1 =>  (0x00007fffadff5000)
	libmaptool_core.so => /usr/lib64/navit/libmaptool_core.so (0x00007fcfddc86000)
	libnavit_core.so => /usr/lib64/navit/libnavit_core.so (0x00007fcfdd9fa000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003b2c600000)
	libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x0000003da8600000)
	libgmodule-2.0.so.0 => /lib64/libgmodule-2.0.so.0 (0x0000003da9200000)
	libz.so.1 => /lib64/libz.so.1 (0x0000003b2ca00000)
	libcrypto.so.10 => /lib64/libcrypto.so.10 (0x000000363ea00000)
	libpng15.so.15 => /lib64/libpng15.so.15 (0x0000003b31200000)
	libdl.so.2 => /lib64/libdl.so.2 (0x0000003b2c200000)
	libm.so.6 => /lib64/libm.so.6 (0x0000003b2be00000)
	libfib.so => /usr/lib64/navit/libfib.so (0x00007fcfdd7f5000)
	libc.so.6 => /lib64/libc.so.6 (0x0000003b2ba00000)
	/lib64/ld-linux-x86-64.so.2 (0x0000003b2b600000)
ldd /usr/bin/navit
	linux-vdso.so.1 =>  (0x00007fff3435a000)
	libnavit_core.so => /usr/lib64/navit/libnavit_core.so (0x00007fe50fc31000)
	libfib.so => /usr/lib64/navit/libfib.so (0x00007fe50fa2d000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003b2c600000)
	libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x0000003da8600000)
	libgmodule-2.0.so.0 => /lib64/libgmodule-2.0.so.0 (0x0000003da9200000)
	libz.so.1 => /lib64/libz.so.1 (0x0000003b2ca00000)
	libcrypto.so.10 => /lib64/libcrypto.so.10 (0x000000363ea00000)
	libpng15.so.15 => /lib64/libpng15.so.15 (0x0000003b31200000)
	libdl.so.2 => /lib64/libdl.so.2 (0x0000003b2c200000)
	libm.so.6 => /lib64/libm.so.6 (0x0000003b2be00000)
	libc.so.6 => /lib64/libc.so.6 (0x0000003b2ba00000)
	/lib64/ld-linux-x86-64.so.2 (0x0000003b2b600000)

In this constellation "libnavit_core.so" for example can used by both tools and must not linked static in both.

comment:7 in reply to: ↑ 6 Changed 6 years ago by sleske

  • Cc sebastian.leske@… added

Replying to http://wiki.navit-project.org/index.php/user:tuxmaster:

The idea behind was, that the maptool and the navit program will get smaller, because navit self and maptool use lot code together.

Hm, yes, that makes sense. On the other hand, I'm not certain the savings are worth it; at least running the binaries directly from the build directory would become harder. I'll have to think about this...

comment:8 Changed 6 years ago by sleske

I tested the effect of -DSHARED_LIBNAVIT=true plus -DBUILD_SHARED_LIBS=true (all values in kB):

sharedstatic
navit 4 512
libnavit 576
maptool 32 736
libmaptool 240
sum 8521248

That is on Linux (x86), with GCC 4.6.4, all binaries stripped.

As you can see, for navit alone using a shared lib actually needs more space (68kB). With navit+maptool, shared libs save about 400k.

comment:9 Changed 6 years ago by sleske

  • Resolution set to fixed
  • Status changed from assigned to closed

Since there does not appear to be a reason for using a shared libnavit_core, I removed the feature flag SHARED_LIBNAVIT to avoid confusion (r.5810). libnavit_core is still built as a shared lib for Android only.

Note: See TracTickets for help on using tickets.