Considering that it hasn't been much activity around the internal libraries for long time, I was wondering if it still makes sense to keep them like they are or merge them in the core.
Recently, during the devel meeting, I relocated a couple of them to the archive. The `lib/binrpc` (and `print`) can have the same fate, being not actually used.
The srdb1 is very common and I guess it is very rare the case when a deployment is used without a module not depending on it (e.g., even if dispatcher is used with a list file, the code is still linked to this library). The `trie` library is small and `ims` is actually a set of getter functions for message attribtues/headers.
The `srdb2` is not used much, but I think the right approach for it is to change the modules using it to `libsrdb1` and get rid of it completely sometime in the future. Till then the code is not big and can reside as part of the core.
The benefits I see are in simplifying the build system (current makefiles and hopefully soon-to-be-merged the one based on cmake), reducing also the time to compute compile and link dependencies; getting rid of packaging complexity (same library may be needed by different modules, which, when packaged separately, the library has to be in a 3rd package, or have dependency of the other module's package -- probably now the libs are shipped with the core package).
The code for libs can stay at the same location, so source code for modules doesn't need to be updated, just that they are compiled with the core, removing internal libs from makefiles.
Thinking that we go for 6.0.x, clarifying the plans for this component and cleaning it, if decided so, should fit well in such version number jump.
Opinions?
Just pushed the changes to compile/link internal libs to the core for the old-Makefiles build system. I did individual commits just in case it will be needed to revert when some modules get changed/archived.
@xkaraman: do you want to update CMake files for the same purpose: compile/link code from src/lib/{srdb1,srdb2,ims,trie} to the core and remove building/linking of internal libs by modules? I can look into it if you have any constraints.
@miconda So all modules should now be linked to kamailio core and not individual "external" libraries. And core is linked with **all** of the libraries in `lib`?
@xkaraman: no, it is about the internal libraries whose code is inside the folders `src/lib/{srdb1,srdb2,ims,trie}`. Instead of building the code in those folders as internal libraries (that were then used by the modules (like acc, msilo, carrierroute, ...)), the code is compiled as part of the core. So, for example, acc no longer needs to be linked to libsrdb1, carrierroute no longer needs to be linked to libsrdb1 and libtrie.
But the external libraries are sill used/linked as they are now (e.g., libssl, libjansson, ...).
In short, it is about removing dependency in modules' cmake-files of any lib from `src/lib/*` and the kamailio binary (the core) is compiling/linking also the *.c files from `src/lib/{srdb1,srdb2,ims,trie}`.
Looking quickly, my guess is that for `acc` module, the next line has to be removed:
``` target_link_libraries(acc PRIVATE srdb1) ```
For `db_redis`, next line is kept:
``` target_link_libraries(db_redis PRIVATE kamailio redis::redis) ``` And next line is removed:
``` target_link_libraries(db_redis PRIVATE srdb1 srdb2) ```
Got it! It was my mistake referring to `libs/` as "external" when you already described them as internal.
Ok I will take a look it at and I ll create a PR for it to be sure, what I implement is the expected!
@xkaraman: after merging the PR #4059, all the modules seem to be compiled/linked together with the code of former libraries, for example for xlog module, I see:
``` [ 98%] Building C object src/modules/xlog/CMakeFiles/xlog.dir/xl_lib.c.o [ 98%] Building C object src/modules/xlog/CMakeFiles/xlog.dir/xlog.c.o [ 98%] Building C object src/modules/xlog/CMakeFiles/xlog.dir/__/__/lib/ims/ims_getters.c.o [ 98%] Building C object src/modules/xlog/CMakeFiles/xlog.dir/__/__/lib/srdb1/db.c.o [ 98%] Building C object src/modules/xlog/CMakeFiles/xlog.dir/__/__/lib/srdb1/db_id.c.o [ 98%] Building C object src/modules/xlog/CMakeFiles/xlog.dir/__/__/lib/srdb1/db_pool.c.o [ 98%] Building C object src/modules/xlog/CMakeFiles/xlog.dir/__/__/lib/srdb1/db_query.c.o [ 98%] Building C object src/modules/xlog/CMakeFiles/xlog.dir/__/__/lib/srdb1/db_res.c.o [ 98%] Building C object src/modules/xlog/CMakeFiles/xlog.dir/__/__/lib/srdb1/db_row.c.o [ 98%] Building C object src/modules/xlog/CMakeFiles/xlog.dir/__/__/lib/srdb1/db_ut.c.o [ 98%] Building C object src/modules/xlog/CMakeFiles/xlog.dir/__/__/lib/srdb1/db_val.c.o [ 98%] Building C object src/modules/xlog/CMakeFiles/xlog.dir/__/__/lib/srdb2/db.c.o [100%] Building C object src/modules/xlog/CMakeFiles/xlog.dir/__/__/lib/srdb2/db_cmd.c.o [100%] Building C object src/modules/xlog/CMakeFiles/xlog.dir/__/__/lib/srdb2/db_con.c.o [100%] Building C object src/modules/xlog/CMakeFiles/xlog.dir/__/__/lib/srdb2/db_ctx.c.o [100%] Building C object src/modules/xlog/CMakeFiles/xlog.dir/__/__/lib/srdb2/db_drv.c.o [100%] Building C object src/modules/xlog/CMakeFiles/xlog.dir/__/__/lib/srdb2/db_fld.c.o [100%] Building C object src/modules/xlog/CMakeFiles/xlog.dir/__/__/lib/srdb2/db_gen.c.o [100%] Building C object src/modules/xlog/CMakeFiles/xlog.dir/__/__/lib/srdb2/db_pool.c.o [100%] Building C object src/modules/xlog/CMakeFiles/xlog.dir/__/__/lib/srdb2/db_rec.c.o [100%] Building C object src/modules/xlog/CMakeFiles/xlog.dir/__/__/lib/srdb2/db_res.c.o [100%] Building C object src/modules/xlog/CMakeFiles/xlog.dir/__/__/lib/srdb2/db_uri.c.o [100%] Building C object src/modules/xlog/CMakeFiles/xlog.dir/__/__/lib/trie/dtrie.c.o [100%] Linking C shared library xlog.so ```
The xlog.so generated is 618368 bytes, while the one build with old makefiles is 128112 bytes.
Definitely something has to be adjusted, because the modules must not be compiled/linked in this way. `xlog` is anyhow not needing any of these former libs.
@miconda Pushed new updates that should now behave as expected. Can you confirm it?
I think the part related to the internal libraries is completed.
Regarding the `-pthread`, it is always required by the core because of multi-threaded UDP reading, before it was needed when overwritting pthread locks for tls with libssl1.1+. The modules that need -ptheard should have it in their (old-)Makefile. for example:
``` src/modules/cdp/Makefile 28: LIBS += -lpthread ```
Thanks. Ok, then we should add the pthread only to the modules that need it. Right now its seems to be active for all modules:
``` kamailio/src/modules/auth$ make clean; make Q=0 [..] gcc -shared -g -pthread -m64 -Wl,-O2 -Wl,-E -rdynamic "-ldl" -Wl,-Bsymbolic-functions nonce.o nc.o challenge.o ot_nonce.o rfc2617.o nid.o rfc2617_sha256.o api.o auth_mod.o -o auth.so kamailio/src/modules/auth$ grep thread Makefile kamailio/src/modules/auth$
kamailio/src/modules/xlog$ make clean; make Q=0 [..] gcc -shared -g -pthread -m64 -Wl,-O2 -Wl,-E -rdynamic "-ldl" -Wl,-Bsymbolic-functions xl_lib.o xlog.o -o xlog.so kamailio/src/modules/xlog$ grep thread Makefile kamailio/src/modules/xlog$ ```
It is indeed passed to all modules, I expected that it was passed to the core only and the modules that needed had it in their Makefiles.
Now I wonder if that is actually needed for all (or most) modules, that can indirectly link to libssl somehow. I cheked with 5.8 and -thread is given there as well, so it can stay like it is, for all.
Yeah, seems to be not actually linked even if its included in the build. Its probably cleaner to not add it, but lets have Xenofon have a look, not want to add more unneeded complexity to the build infrastructure.
``` kamailio/src/modules/xlog$ ldd xlog.so linux-vdso.so.1 (0x00007ffe2ff42000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f39fff77000) /lib64/ld-linux-x86-64.so.2 (0x00007f3a00198000) $ ```
This issue is stale because it has been open 6 weeks with no activity. Remove stale label or comment or this will be closed in 2 weeks.
Closed #4041 as completed.
Internal libraries now compiled to core.
-
Daniel-Constantin Mierla -
github-actions[bot]
-
Henning Westerholt
-
Xenofon Karamanos