A LOCK_METHOD problem: There's a LOCK_METHOD variable in defs.cmake:

https://github.com/kamailio/kamailio/blob/6b0b8cb84b7d0e965d50bdf0dfa5423004879f55/cmake/defs.cmake#L171-L179

And the explicit usage LOCK_METHOD as USE_FUTEX in a compile_definitions:
https://github.com/kamailio/kamailio/blob/6b0b8cb84b7d0e965d50bdf0dfa5423004879f55/cmake/defs.cmake#L304-L327

I suppose it's incorrect while some OSs (FreeBSD, ex.) doesn't tested with futexlock.h earlier.

That is the default one used if none is provided.
If FreeBSD requires some other we can overwrite the value in the freebsd.cmake to have a more reasonable one. Or use an empty string and maybe force the user to choose the appropriate one, which seems to break the common build case.
There should also be a way to offer only supported ones per OS, but that might need some more changes but might be worth it in the end.
@henningw @miconda Thoughts on this?

A resolv-link problem: There're an explicit links of the resolv library:

https://github.com/kamailio/kamailio/blob/6b0b8cb84b7d0e965d50bdf0dfa5423004879f55/src/CMakeLists.txt#L116-L124

https://github.com/kamailio/kamailio/blob/6b0b8cb84b7d0e965d50bdf0dfa5423004879f55/utils/kamcmd/CMakeLists.txt#L32

I think it's incorrect while some OSs (FreeBSD, ex.) uses builtin resolv (libc, etc).
Initially сmake is built successful after the above fixes.

So, for you to build you have removed the link against resolv? Or you mean did it compile with unnessecary linkage

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.