cmake build incomplete when use SHARED_LIBNAVIT

[tuxmaster]

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

[sleske]

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.

[sleske]

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

[tuxmaster]

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

[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 :-).

[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.

[sleske]

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...

[sleske]

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

	shared	static
navit	4	512
libnavit	576
maptool	32	736
libmaptool	240
sum	852	1248

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.

[sleske]

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.