15 Jan
2025
15 Jan
'25
1:19 a.m.
A `LOCK_METHOD` problem: There's a `LOCK_METHOD`
variable in defs.cmake:
https://github.com/kamailio/kamailio/blob/6b0b8cb84b7d0e965d50bdf0dfa542300…
And the explicit usage `LOCK_METHOD` as `USE_FUTEX` in a compile_definitions:
https://github.com/kamailio/kamailio/blob/6b0b8cb84b7d0e965d50bdf0dfa542300…
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/6b0b8cb84b7d0e965d50bdf0dfa542300…
https://github.com/kamailio/kamailio/blob/6b0b8cb84b7d0e965d50bdf0dfa542300…
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/c2590043925(a)github.com>