Opened 9 years ago
Closed 9 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 9 years ago by usul
- Description modified (diff)
- Keywords cmake build libs added
- Milestone set to version 0.5.1
comment:2 Changed 9 years ago by sleske
- Owner changed from KaZeR to sleske
- Priority changed from major to minor
- Status changed from new to assigned
comment:3 Changed 9 years ago by sleske
Also, please indicate your build environment (OS and CMake version).
comment:4 follow-up: ↓ 5 Changed 9 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 9 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: ↓ 7 Changed 9 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 9 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 9 years ago by 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.
comment:9 Changed 9 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.
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.