When attempting to start Kamailio 5.0.0 with the app_perl module, it fails to start and logs:
Mar 1 10:20:04 albatross kamailio: DEBUG: <core> [core/sr_module.c:575]: load_module(): trying to load </lib64/kamailio/m odules/app_perl.so> Mar 1 10:20:04 albatross kamailio: ERROR: <core> [core/sr_module.c:582]: load_module(): could not open module </lib64/kam ailio/modules/app_perl.so>: /lib64/kamailio/modules/app_perl.so: undefined symbol: sv2int_str Mar 1 10:20:04 albatross kamailio: CRITICAL: <core> [core/cfg.y:3400]: yyerror_at(): parse error in config file /opt/ensw itch/current/etc/kamailio/kamailio_50.cfg, line 28, column 12-21: failed to load module
The machine is Ubuntu 16.10, line 28 of kamailio_50.cfg is:
loadmodule "app_perl"
and the other options passed to app_perl are:
modparam( "app_perl", "filename", "/opt/enswitch/current/perllib/Integrics/Enswitch/Kamailio.pm" ) modparam( "app_perl", "modpath", "/opt/enswitch/current/perllib" ) modparam( "app_perl", "reset_cycles", 100000 ) modparam( "app_perl", "perl_destroy_func", "Integrics::Enswitch::Kamailio::restart" )
This problem does not happen on the same machine with Kamailio 4.2.1 and an identical configuration file.
Hello Alistair,
Could you provide the output of:
ldd {module path}/mod_perl.so
?
Thanks,
-- Alex
By which I certainly meant `app_perl.so`.
Certainly:
root@albatross:/lib64/kamailio/modules# ldd app_perl.so linux-vdso.so.1 => (0x00007ffc2bb9c000) libperl.so.5.22 => /usr/lib/x86_64-linux-gnu/libperl.so.5.22 (0x00007f823470f000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f82344f1000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f823412a000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f8233f26000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f8233c1d000) libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f82339e3000) /lib64/ld-linux-x86-64.so.2 (0x000055ebaa31a000)
The function sv2int_str is defined in kamailio/src/modules/app_perl/kamailioxs.xs as inline.
Which is why it does not show up in the .o or, therefor, the .so.
The question is what expects it as a symbol?
Removing inline from its definition may be a quick workaround.
-JimC
It looks like adding CC_OPT=-O2 to the make invocation works around this.
W/ optimization gcc elides the inlined symbol, and that should allow the .so to load.
I can confirm that CC_OPT=-O2 solves the problem. I've added this to our installer, so it solves the problem for us. It would still be good to fix this for others.
If the function is not used in the same object (source file) only, then inline should be removed, because it doesn't do anything and it is not seen as symbol to other object files. If anyone can provide a pull request, then it will be merged, if not I will do it during next days.
"DM" == Daniel-Constantin Mierla notifications@github.com writes:
DM> If the function is not used in the same object (source file) only, DM> then inline should be removed,
It is only used in the .xs file where it is defined.
Without optimization gcc (at least gcc 5) leaves it in the .o file as an undefined symbol.
I just duplicated what kamailio master does to make(1) kamailioxs.s, but with -S instead of -c. The four places where sv2int_str() is called show up as:
call sv2int_str@PLT
With -O2 or -O1 it gets inlined.
So it seems that w/o optimization gcc5 fails to inline the function at its call sites, but also leaves it out because it was defined as inline.
Gcc-4.8, OTOH, compiles it as a non-inlined function called run w/o optimization.
So this is a gcc bug which kamailio can work around by optimizing.
I see in Makefile.defs that CC_OPT defaults to -O3 when using clang. And before that it is ?='ed to -O9. But that -O9 didn't make it into the gcc calls when I tried compiling with Q=0.
To test, make kama however you normally do, then:
cd src/modules/app_perl rm kamailioxs.o make kamailioxs.o Q=0
copy the resulting cc line, replacing -c with -S and kamailioxs.o with kamailioxs.s and search for sv2int_str in that kamailioxs.s.
-JimC
It turns out this inline difference is not a bug but rather a C89 vs C11 difference, and gcc5 switched from -std=gnu89 to -std=gnu11 by default.
So removing the inline is not a bad idea.
Or better yet adding static.
I'll send a pull request for adding static to that declaration.
A quick test shows that adding static works.
-JimC
Fixed by 42d3b93f838d1c2eeb009894422fe016a6572520.
Closed #1012.
-
Alex Balashov -
Alex Balashov -
Alistair Cunningham
-
Daniel-Constantin Mierla
-
James Cloos