> 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 or view it on GitHub:
https://github.com/kamailio/kamailio/pull/4104#issuecomment-2590043925
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/pull/4104/c2590043...@github.com>
_______________________________________________
Kamailio - Development Mailing List -- sr-dev@lists.kamailio.org
To unsubscribe send an email to sr-dev-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the
sender!
