I'm working on adding 5.3.3 to pkgsrc, and have run into a few minor
things. I'm mentioning them here in the hopes of being steered towards
the preferred way to fix.
(I hope this belongs on -dev; let me know if not.)
1) -ldl
In src/Makefile.defs, I had to do:
-LD_PMUTEX_OPTS = -pthread -rdynamic -ldl -Wl,-Bsymbolic-functions
+LD_PMUTEX_OPTS = -pthread -rdynamic -Wl,-Bsymbolic-functions
because on NetBSD there is no -ldl and dlopen is just in libc.
My suggested fix is to define a LD_LIBDL per OS and use that variable
instead when it would be needed.
2) lib64
I did
-LIBDIR ?=
-ifeq ($(LIBDIR),)
-ARCHBSZ= $(shell echo $(ARCH) | sed -e 's/.*64.*/64b/')
-ifeq ($(ARCHBSZ),64b)
- LIBDIR = lib64
-else
- LIBDIR = lib
-endif
-endif
+LIBDIR = lib
because on NetBSD native libs always go in lib, and we put emulated
(other arch that can be run, so i386 on amd64 is considered emulated) in
/emul/foo. As I understand it this is true on other BSDs, Solaris, and
probably things like AIX and IRIX.
So I would suggest that this be guarded with an "if linux". Perhaps
there are other systems that also want lib64.
3) namespace visibility
In src/lib/srdb1/db_ut.c there is some complicated namespace visibility
macro use, to ensure strptime is vailable. Then after setting one,
there are others to recover from that. On NetBSD, it didn't recover. I
ripped it all out and
+#define _NETBSD_SOURCE
+#include <sys/types.h>
which isn't right either of course.
What I'd suggest is to avoid any namespace mucking except on a
particular system and version of that system known to need it, as mostly
things seem to go better with no visibility definitions.
I also have found problems with changing the visibility defines, running
into a situation where one header hid something but then later when it
shouldn't have been some other header wanted to include the first
header, but it had already been processed.
And, the code as is doens't seem to undo the defines after including,
even though it seems to try to.
Thanks for any hints,
Greg
My next issue in the NetBSD build is about mutexes. I gather this is
very much about openssl 1.1, and all of this is only about non-Linux
since there futexes are used. (pkgsrc has switched to openssl 1.1
basically the beginning of 2020.)
I am guessing that the basic issue is that the pthread mutexes are
placed in shared memory and used from multiple processes, and that
regardless of setting attributes, the point is that these need to work
in that environment, and if not, some other synchronization scheme needs
to be chosen. And, I gather the problem is lack of a wakeup on release
to blocked threads in other processes. Close?
There is -DKSR_PTHREAD_MUTEX_SHARED defined:
ifeq ($(LIBSSL_SET_MUTEX_SHARED), 1)
CC_PMUTEX_OPTS = -pthread -DKSR_PTHREAD_MUTEX_SHARED
LD_PMUTEX_OPTS = -pthread -rdynamic -Wl,-Bsymbolic-functions
else
CC_PMUTEX_OPTS =
LD_PMUTEX_OPTS =
endif
and this seems to get turned on regardless of which mutex option an OS
uses.
Later, in the netbsd if chunk
ifneq ($(found_lock_method), yes)
C_DEFS+= -DUSE_SYSV_SEM # try pthread sems
found_lock_method=yes
but then -DKSR_PTHREAD_MUTEX_SHARED is still on, and the code that usss
pthread_mutexattr_setpshared is compiled in. I am thinking it might not
be used, because of SYSV_SEM.
(Btw, the check for NetBSD > 2.0.0 and kqueue can be removed; we support
only 8 and 9 now, and while I don't like to gratuitously desupport older
versions, I really doubt current kamailo would build on anything earlier
than 6 anyway. Similar for FreeBSD probably, but I don't want to speak
for them.)
Thanks,
Greg
Module: kamailio
Branch: master
Commit: 19c6f596f1daf246c0f77236ecf0016bfc3c81a2
URL: https://github.com/kamailio/kamailio/commit/19c6f596f1daf246c0f77236ecf0016…
Author: Kamailio Dev <kamailio.dev(a)kamailio.org>
Committer: Kamailio Dev <kamailio.dev(a)kamailio.org>
Date: 2020-03-16T16:01:17+01:00
modules: readme files regenerated - p_usrloc ... [skip ci]
---
Modified: src/modules/p_usrloc/README
---
Diff: https://github.com/kamailio/kamailio/commit/19c6f596f1daf246c0f77236ecf0016…
Patch: https://github.com/kamailio/kamailio/commit/19c6f596f1daf246c0f77236ecf0016…
---
diff --git a/src/modules/p_usrloc/README b/src/modules/p_usrloc/README
index c04e890fdf..84a7c37eba 100644
--- a/src/modules/p_usrloc/README
+++ b/src/modules/p_usrloc/README
@@ -619,18 +619,19 @@ modparam("p_usrloc", "default_db_type", "cluster")
3.25. db_ops_ruid (int)
- If set to 1, database queries for update or delete are done using ruid
- value. If it is set to 0, the old style using aor, contact and call-id
- is done.
+ Defines how database queries are done:
+ * 0 uses the old style using aor, contact and call-id
+ * 1 uses ruid value
+ * 2 uses the new style using aor, contact and call-id
- Default value is “0”.
+ Default value is 0
Can be set at runtime, e.g.:
$ kamcmd cfg.set_now_int p_usrloc db_ops_ruid 1
Example 1.25. Set db_ops_ruid parameter
...
-modparam("p_usrloc", "db_ops_ruid", 0)
+modparam("p_usrloc", "db_ops_ruid", 2)
...
3.26. db_update_as_insert (string)
Hello,
Kamailio SIP Server v5.3.3 stable release is out.
This is a maintenance release of the latest stable branch, 5.3, that
includes fixes since the release of v5.3.2. There is no change to
database schema or configuration language structure that you have to do
on previous installations of v5.3.x. Deployments running previous v5.3.x
versions are strongly recommended to be upgraded to v5.3.3.
For more details about version 5.3.3 (including links and guidelines to
download the tarball or from GIT repository), visit:
* https://www.kamailio.org/w/2020/03/kamailio-v5-3-3-released/
RPM, Debian/Ubuntu packages will be available soon as well.
Many thanks to all contributing and using Kamailio!
Special circumstances are now everywhere word wide, impacting all of us,
therefore we wish a smooth time during this crisis and to stay healthy
to all our developers, supporters and community members along with
their beloved ones!
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
Add also new "uniq" column.
The new update function will use this new column.
<!-- Kamailio Pull Request Template -->
<!--
IMPORTANT:
- for detailed contributing guidelines, read:
https://github.com/kamailio/kamailio/blob/master/.github/CONTRIBUTING.md
- pull requests must be done to master branch, unless they are backports
of fixes from master branch to a stable branch
- backports to stable branches must be done with 'git cherry-pick -x ...'
- code is contributed under BSD for core and main components (tm, sl, auth, tls)
- code is contributed GPLv2 or a compatible license for the other components
- GPL code is contributed with OpenSSL licensing exception
-->
#### Pre-Submission Checklist
<!-- Go over all points below, and after creating the PR, tick all the checkboxes that apply -->
<!-- All points should be verified, otherwise, read the CONTRIBUTING guidelines from above-->
<!-- If you're unsure about any of these, don't hesitate to ask on sr-dev mailing list -->
- [X] Commit message has the format required by CONTRIBUTING guide
- [X] Commits are split per component (core, individual modules, libs, utils, ...)
- [X] Each component has a single commit (if not, squash them into one commit)
- [X] No commits to README files for modules (changes must be done to docbook files
in `doc/` subfolder, the README file is autogenerated)
#### Type Of Change
- [ ] Small bug fix (non-breaking change which fixes an issue)
- [X] New feature (non-breaking change which adds new functionality)
- [ ] Breaking change (fix or feature that would change existing functionality)
#### Checklist:
<!-- Go over all points below, and after creating the PR, tick the checkboxes that apply -->
- [ ] PR should be backported to stable branches
- [X] Tested changes locally
- [ ] Related to issue #XXXX (replace XXXX with an open issue number)
#### Description
<!-- Describe your changes in detail -->
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/2253
-- Commit Summary --
* p_usrloc: add new update function
-- File Changes --
M src/modules/p_usrloc/config.c (2)
M src/modules/p_usrloc/doc/p_usrloc_admin.xml (27)
M src/modules/p_usrloc/p_usrloc_mod.c (4)
M src/modules/p_usrloc/p_usrloc_mod.h (1)
M src/modules/p_usrloc/ucontact.c (265)
M src/modules/usrloc/usrloc.h (1)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/2253.patchhttps://github.com/kamailio/kamailio/pull/2253.diff
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/pull/2253
Source:
https://www.kamailioworld.com/k08/2020/03/kamailio-world-2020-event-cancell…
It is probably no much of a surprise that the next Kamailio World
Conference and the NG-Emergency track cannot be organized any more
during April 27-29, 2020. We are trying to find out the best
alternatives for later in the year, when we hope the situation will be
back to normal and people will be again in mood for social interaction.
Being one of proposed alternatives, because we discussed a lot during
the last several days with the people involved in organizing the event
as well as its active community, we want to make it clear right now that
we do not plan to switch to an online version (i.e., video conferencing)
at the same dates. With the current situation out there, it is very
likely that the level of stress everywhere will be high during the next
6 weeks till the initial planned dates, so putting together the
infrastructure for video conferencing, synchronizing with the speakers
and participants will just add to it, therefore it is better that
everyone is focusing on taking care of the beloved ones and how to deal
the best with the daily constraints during this interval.
All the payments received for participating at or supporting Kamailio
World 2020 will be refunded. If you are among them, thank you once more!
We will contact you very soon with the relevant details.
Keep also an eye on the event website for updates related to what is
going to be next related to the conference!
We hope the evolution will turn into a positive perspective very soon
and the crisis is going to end rapidly, so everyone can return to the
usual activities! Moreover, we wish you and the beloved ones a smooth
time during this exceptional situation and to stay healthy!
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda