How to print version of ncurses from Perl - perl

How can I print the version of the ncurses library? I use the Curses library from Perl. I do not care much about the version of the CTAN package which from what I understand is just the interface to access the curses library.
I downloaded the latest (unstable) version of ncurses from here:
http://invisible-island.net/datafiles/current/ncurses.tar.gz
I compiled it without error (with just ./configure and make) but have not yet done sudo make install
I would like to know how to (1) check which version of curses is installed and eventually (2) switch between versions.
Note that I am on Ubuntu 13.04. Perhaps the following information is helpful:
$ locate ncurses.h
/usr/include/ncurses.h
$ locate curses.h
/usr/include/curses.h
/usr/include/ncurses.h
/usr/include/python2.7/py_curses.h
$

It seems that indeed there is no function in Curses.pm to get the current (n)curses version.
You can write a small C program to get the value:
/* compile with "cc -lcurses filename.c" */
#include <curses.h>
main() {
printf("%s\n", curses_version());
}
On my system this prints ncurses 5.7.20100313.
But it would also be nice to have the curses_version() function also available from Curses.pm — maybe ask the Curses.pm author?

Do you have ncurses5-config (or ncurses-config, ncurses4-config, etc...) on your system? I for instance can do this on my CentOS 6 system:
$ ncurses5-config --version
5.7.20090207
which you could call from perl also:
my $ncurses_version = qx(ncurses5-config --version);
If you are working with different major versions, you might have to try a couple ncurses*-config commands, e.g.:
my $nc_version;
for my $nc (qw'ncurses-config ncurses5-config ncurses4-config') {
no warnings 'exec';
$nc_version = qx($nc --version) and last;
}
print "nc_version=$nc_version\n";
Hope this helps you,
Christian

Related

Perl undefined yp_get_default_domain detected by DynaLoader.pm when using ARSperl, yet library exists

I have a Ubuntu server that recently pushed a Perl update to 5.14.2 when I installed cpanminus. This broke compatibility with the BMC Remedy API module. It looks like I can't roll back to the old version of Perl, so I've tried recompiling ARSperl for Perl 5.14.2.
The problem is, when I run an old Perl script that used the old module, I get the following:
Can't load '/usr/local/lib/perl5/5.14.2/auto/ARS/ARS.so' for module ARS:
/usr/local/lib/perl5/5.14.2/auto/ARS/ARS.so: undefined symbol:
yp_get_default_domain at /usr/local/lib/perl5/5.14.2/i686-linux/DynaLoader.pm line 190.
So, a bit of Googling tells me that yp_get_default_domain lives in libnsl. I've gone so far as to try recompiling both the ARSperl module and Perl itself with "-lnsl" explicitly called out in the Makefile. Unfortunately, this has gotten me nowhere. The library is indeed installed on the system under /usr/lib/i386-linux-gnu/.
In ARSperl Makefile:
LDFLAGS = -fstack-protector -L/usr/local/lib -L/usr/lib -L/usr/lib/i386-linux-gnu -lnsl
My question is therefore two-fold for the Perl gurus out there.
-How can I determine which of Perl, DynaLoader, or the ARS.so itself can't find "yp_get_default_domain"?
-What is the best next step to troubleshoot the above DynaLoader message for a missing library that is actually present on the system and linked in the module?
Thank you in advance for sharing your knowledge and advice.
Add the directory where library is installed to the $ARS_LDPATH in Makefile.PL
Something like
$ARSAPI = "C:\\ARS_Library\\api764win";
if( $WINDOWS ){
$ARS_LDPATH = qq{-L"$ARSAPI/lib"};
$INCLUDES = qq{-I"$ARSAPI/include"};
}else{
$ARS_LDPATH = "-L$ARSAPI/lib";
$INCLUDES = "-I$ARSAPI/include";
}
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.
Thank you Chankey Pathak for pointing me toward the Makefile.PL, I wouldn't have immediately started looking at changing things there without this advice.

install CPAN module ClearCase::CtCmd

I need to install the CPAN module ClearCase::CtCmd. I have downloaded the module CtCmd-1.09. After running the command perl Makefile.PL I am having the following errors:
perl Makefile.PL
Looking for ClearCase version 7 Found 7.1
Looking for gcc version 2.7 Found 3.4
Looking for SunOS 5.7 Found 5.8
Checking if your kit is complete...
Use of uninitialized value in chdir at /usr/local/lib/perl5/5.8.5/File/Find.pm line 741.
Use of chdir('') or chdir(undef) as chdir() is deprecated at /usr/local/lib/perl5/5.8.5/File/Find.pm line 741.
Looks good
Could not open 'CtCmd.pm': No such file or directory at /usr/local/lib/perl5/5.8.5/ExtUtils/MM_Unix.pm line 3079.
I mention that the perl version is v5.8.5. In the INSTALL file it is stated that "The ClearCase::CtCmd module requires Perl v5.6.1 or v5.8 or later."
What type of machine is this on? Solaris? Doesn't ClearCase come with its own version of Perl that already includes ClearCase::CtCmd?
Use of uninitialized value in chdir at /usr/local/lib/perl5/5.8.5/File/Find.pm line 741.
Use of chdir('') or chdir(undef) as chdir() is deprecated at /usr/local/lib/perl5/5.8.5/File/Find.pm line 741.
Looks good
File::Find is a standard Perl module. The uninitialized value in chdir does not look good.
Could not open 'CtCmd.pm': No such file or directory at /usr/local/lib/perl5/5.8.5/ExtUtils/MM_Unix.pm line 3079.
ExecUtils/MakeMaker is calling ExtUtils/MM_Unix.pm and is trying to write your Makefile. I have a feeling it's suppose to locate where CtCmd.pm is located from File::Find and with File::Find failing, MakeMaker can't create the Makefile.
I'm looking at the Makefile.PL and see that it requires $ATRIA_ROOT to be set, or otherwise, it's inferred as being at /opt/rational/clearcase. Could this have something to do with it?
No. Doesn't look like it. Otherwise, you wouldn't have gotten the report on the ClearCase version. And, I guess the system is Solaris because that's the only place where the gcc version is being searched.
I think it's time to do a bit of munging in the Makefile.PL program to see what it's doing. I notice in line #218 is WriteMakefile(%opts); I would add a little routine to print out this %opts subroutine (probably using warn instead of print). This subroutine is from ExtUtils::MakeFile which actually writes the Makefile. It might give you a clue to what's going on.
Unfortunately, the problem looks like it has to do with the way ExtUtils::MakeMaker is working. Using Perl 5.8.5 means you have an older, buggier version of ExtUtils::MakeMaker. You can look at the release notes of ExtUtils::MakeMaker and see if that offers you any clue. Perl 5.8.5 is no longer supported. It's a very, very old version of Perl.

Building a perl extension module on OpenBSD

How ought I build an XS perl module on OpenBSD when the requisite .so files are missing?
Background: On a vanilla OpenBSD 5.3 vm install, I'm unable to build a perl module which needs to link against -lpthread. pthread.a and pthread.so.Maj.Min do exist on the system.
However Makefile.PL is looking for pthread.so, which is absent. Is this ordinary for OpenBSD? (I can coerce the Makefile to link against pthread.a and things work just fine, as it happens.)
In a Redhat-ish Linux environment, I'd just install the right -devel RPM and go again. On OpenBSD, however, I'm missing something very basic about the development environment.
UPDATE The core problem was Dynaloader mis-detection of libraries inside Makefile.PL.
The Makefile is wrong, report the bug to the upstream. It never should look for a specific file. Look this example:
$ cat test.c
int main(){
return 0;
}
$ gcc -lpthread -o test test.c
$ ldd test
test:
Start End Type Open Ref GrpRef Name
00000c4321600000 00000c4321a02000 exe 1 0 0 test
00000c4521f63000 00000c4522374000 rlib 0 2 0 /usr/lib/libpthread.so.17.1
00000c4524c1c000 00000c4525103000 rlib 0 1 0 /usr/lib/libc.so.68.2
00000c452a100000 00000c452a100000 rtld 0 1 0 /usr/libexec/ld.so
Also, in OpenBSD you don't need install a -devel package. OpenBSD has the batteries included.
While editing your Makefile.PL is one way to go, I generally see folks use link files to point generic library/executable names to version specific names.
For Example:
pthread.so -> pthread.so.maj.min
pthread.so.maj -> pthread.so.maj.min
This way things that want the 'latest' version can get it via the link & thinks that just care about major version can grab the most recent release of it's major version...

How do I use a dependency on a Perl module installed in a non-standard location?

I need to install two Perl modules on a web host. Let's call them A::B and X::Y. X::Y depends on A::B (needs A::B to run). Both of them use Module::Install. I have successfully installed A::B into a non-system location using
perl Makefile.PL PREFIX=/non/system/location
make; make test; make install
Now I want to install X::Y, so I try the same thing
perl Makefile.PL PREFIX=/non/system/location
The output is
$ perl Makefile.PL PREFIX=/non/system/location/
Cannot determine perl version info from lib/X/Y.pm
*** Module::AutoInstall version 1.03
*** Checking for Perl dependencies...
[Core Features]
- Test::More ...loaded. (0.94)
- ExtUtils::MakeMaker ...loaded. (6.54 >= 6.11)
- File::ShareDir ...loaded. (1.00)
- A::B ...missing.
==> Auto-install the 1 mandatory module(s) from CPAN? [y]
It can't seem to find A::B in the system, although it is installed, and when it tries to auto-install the module from CPAN, it tries to write it into the system directory (ignoring PREFIX). I have tried using variables like PERL_LIB and LIB on the command line, after PREFIX=..., but nothing I have done seems to work.
I can do make and make install successfully, but I can't do make test because of this problem. Any suggestions?
I found some advice at http://servers.digitaldaze.com/extensions/perl/modules.html to use an environment variable PERL5LIB, but this also doesn't seem to work:
export PERL5LIB=/non/system/location/lib/perl5/
didn't solve the problem.
The answer is local::lib, but you probably already know that :)
OK, the following prescription did it:
perl Makefile.PL --skipdeps --no-manpages PREFIX=/non/system/location INSTALLSITELIB=/non/system/location/lib INSTALLSITEBIN=/non/system/location/bin INSTALLMAN1DIR=/non/system/location/man/man1 INSTALLMAN3DIR=/non/system/location/man/man3
This is just "monkey see monkey do" but now make test works.
The --skipdeps option here suppresses a convenient feature/exasperating problem with Module::Install where it tries to use CPAN.pm to download missing modules.
The --no-manpages is supposed to stop it installing man pages but it doesn't work.
Because this is the top link i thought i'd update with my experience (which has taken a while to get working, hence updating the 7 year old post).
first run perl -le 'print join $/, #INC'
add (note, no / at the end!!)
export PERL5LIB=/nonstddir/scripts/modules/lib/site_perl:/nonstddir/scripts/modules/lib
run perl -le 'print join $/, #INC' make sure the new dirs are added. this makes it work. if you add a / at the end of the path, the INC entry will look weird and wrong. Mine had a // in the middle.
When done and working, mine looks like
/nonstddir/scripts/modules/lib/site_perl/5.8.4/sun4-solaris-64int
/nonstddir/scripts/modules/lib/site_perl/5.8.4
/nonstddir/scripts/modules/lib/site_perl
/nonstddir/scripts/modules/lib/sun4-solaris-64int
/nonstddir/scripts/modules/lib
/usr/perl5/5.8.4/lib/sun4-solaris-64int
/usr/perl5/5.8.4/lib
/usr/perl5/site_perl/5.8.4/sun4-solaris-64int
/usr/perl5/site_perl/5.8.4
/usr/perl5/site_perl
/usr/perl5/vendor_perl/5.8.4/sun4-solaris-64int
/usr/perl5/vendor_perl/5.8.4
/usr/perl5/vendor_perl

How do I compile Perl 5.10 with thread support under FreeBSD 7.1?

I'm trying to compile Perl 5.10 on my FreeBSD 7.1 (BSD) server but when I run the Configure script and answer the questions I get the following error:
...POSTIX threads should be supported by FreeBSD 7.1 ... but your system is missing the shared libc_r.
Googling for the answer came up with installing gethostnamadr.c which is fine except for two things:
I don't know where to put this file and
How does this solve my problem if Configure wants to see libc_r?
To enable Perl 5.10 threads on FreeBSD 7.* all you have to do is apply the following patch using patch. You can then build perl with -Dusethreads or answer the Configure file questions to enable threading and you're good to go. I haven't done any significant testing or comparisons yet but everything compiles fine including the thread libs and all my Perl programs work fine.
--- hints/freebsd.sh 2008/10/20 04:59:30 1.1
+++ hints/freebsd.sh 2008/10/20 22:49:29
## -211,6 +211,14 ##
exit 1
;;
+ 7.*)
+ # 7.x doesn't install libc_r by default, and Configure
+ # would fail in the code following
+ #
+ # gethostbyaddr_r() appears to have been implemented in 6.x+
+ ldflags="-pthread $ldflags"
+ ;;
+
*)
if [ ! -r "$lc_r" ]; then
cat <<EOM >&4
EDIT: I forgot my reference; check here for more info: http://www.gossamer-threads.com/lists/perl/porters/232518?nohighlight=1#232518.
Contrary to Spolsky who said "perl is pretty much forgotten"... perl is very much alive.
You have not indicated which version of FreeBSD you have installed... But assuming that you have installed a min of FreeBSD 7.1 then you failed to install the threads libraries or the thread libs are not in the library path.
NOTE that libc is a general 'c' library and that libc_r is the thread-safe version of that file. Some of the 2005 google results suggest that libc_r has been deprecated.
With that in mind it is likely that you are in the middle of a "revision collision". Sadly FreeBSD does not provide the thread safe version of perl natively, however, they do package perl 5.10 and several later revisions. I found this link to be useful:
http://www.nabble.com/How---where-to-get-a-Perl-that-has-threads--td22270858.html
you might also want to try installing the p5-fork library which is included with FreeBSD
http://www.nabble.com/How---where-to-get-a-Perl-that-has-threads--td22270858.html