undefined symbol: yp_get_default_domain w/libnsl in path.
Brought to you by:
jeffmurphy
Menu
▾
▴
#30 undefined symbol: yp_get_default_domain w/libnsl in path.
Attempting to use ARSperl 1.91 (also tried 1.93, 1.85)
ARS API version 5.1 (I've also tried 6.3),
ARSystem version 6.3,
OS = x86 Ubuntu "wheezy/sid" Kernel 2.6.35-32-generic-pae.
Perl = 5.14.2 (recently updated from 5.10.1)
Upon attempting to execute various query scripts that make use of the API, I get error messages indicating that "yp_get_default_domain" is undefined. Specifically:
Can't load '/usr/local/lib/perl/5.14.2/auto/ARS/ARS.so' for module ARS: /usr/local/lib/perl/5.14.2/auto/ARS/ARS.so: undefined symbol: yp_get_default_domain at /usr/local/share/perl/5.14.2/DynaLoader.pm line 190.
yp_get_default_domain looks to be part of libnsl, which is in the path.
# nm -D /lib/i386-linux-gnu/libnsl.so | grep yp_get
00004170 T yp_get_default_domain
I have attempted to change the Makefile.PL $ARS_LDPATH and $INCLUDES path to this:
$ARS_LDPATH = "-L/lib/i386-linux-gnu"
$INCLUDES = "-I/usr/include"
With the API header and lib files copied over to those include and lib directories. After rebuilding and re-install ARSperl with those modifications, the same error appears.
At this point, as far as I can tell, ARSperl is not recognizing the libnsl library for some reason. The test Perl scripts that perform the queries using ARSperl were known working good with the previous Perl version.
If this is not actually a bug, I can certainly change it to a support request. Either way, I've got a production system that is offline and I could really use some assistance in tracking down why ARSperl will not recognize libnsl. Any advice, input, or recommendations are appreciated.
We updated to ARSperl 1.93, started using AR API version 6.3 rather than 5.1.2 and added "-lsnl" to the ARSperl Makefile.PL $ARS_LIBS in the section for 6.3.
That resulted in Perl segfaulting every time the ARS.so module was run. After lots of testing and trying to diagnose why segfaults were occurring, we recompiled a separate instance of Perl-5.14.2 from source under /opt/ and removed the 64int option. Updating the shebang lines on all our Perl scripts that need the ARS module to redirect to the Perl version under /opt seems to have gotten things working again.
This looks to be resolved now. I've seen documentation elsewhere that indicates the ARS.so module doesn't play nicely with 64-bit Perl, it would seem that even just 64-bit integers within Perl cause problems.