The problem is I don't have access to write $HOME directory. (I only have access to create new directory on $HOME/app-root/data/)
because cpan/cpanm need to create new directory $HOME/.cpan/ I don't have idea how to find all modules dependency by hand (one-by-one).
Do you guys know other method to install module (and find dependency) but without to create ~/.cpan/ directory ?
or maybe how to override ~/.cpan/ to ~/app-root/data/.cpan ?
P.S: Sorry my english is bad, english isn't my native language
Just (temporarily) change $HOME to a directory you do have write access to:
HOME=$HOME/app-root/data/ cpanm Module
[An answer to the literal question is useful to people trying to install on a machine without internet, so I'll answer it even though it's not the best solution for you.]
To find the dependencies, you can use http://deps.cpantesters.org/. For example, here's the dependency tree for a module of mine.
Just list modules you need in .openshift/cpan.txt
Openshift will install it automatically when you deploy
Related
For years I have been using the following at the top of my scripts:
use lib '/var/www/vhosts/example.com/demo.example.com/cgi-bin/library';
That works fine when the lib is within the same domain space as the calling script.
However, I want to call in from a centralised library so I will have just one place to set db credentials.
So, if I adjust that line to call in from another account on the same server, it cannot find the library.
use lib '/var/www/vhosts/example2.com/demo.example2.com/cgi-bin/library';
Running on plesk, if that may make a difference. Used to run on cPanel and I had no issue.
I would appreciate a pointer, having already read some docs and I am confused.
Only someone with access to the configuration of your web server can answer this for sure, but I'd guess that each of your vhosts is running as a different user and the users can only read files from their own web space.
This approach won't work. If you want to to have a centralised module library then either install the modules that you want in the system module library (i.e. where cpan will install them by default) or create your own new centralised library somewhere that isn't under one of the vhost directories (perhaps under /opt).
However, it's worth noting that best practices for deployment of applications are moving in completely the opposite direction. It's generally considered a good idea for each application to have its own set of dependencies installed in its own module library. Using a cpanfile to record the exact versions of the dependencies that you're using makes this simple.
I followed the instructions in GStreamer Plugin Writer's Guide (1.7.1.1):
http://gstreamer.freedesktop.org/data/doc/gstreamer/head/pwg/html/index.html
in order to build a new gstreamer plugin. Basically I ran make_element and then edited Makefile.am as described. Amazingly make and make install worked and I ended up with:
/usr/local/lib/gstreamer-1.0/libgstframe_grabber.la
/usr/local/lib/gstreamer-1.0/libgstframe_grabber.so
As I understand it, gst-inspect should find this plugin automatically. The guide says that /usr/local/lib/gstreamer-1.0 needs to be added to GST_PLUGIN_PATH in order for plugins in this directory to be found. Another document states that this directory is searched automatically. I tried with and without the environment variable, but no luck.
Now I should say that I have just started to use gstreamer and I am suffering from total information overload. I have read so many documents, yet I don't even know whether I am building a gstreamer1.0 or a gstreamer0.10 plugin (I think the guide is for gstreamer1.0, since the guide's version is 1.7.1.1 but can't be sure).
Can anybody give me a clue here ?
There are many possible reasons that can cause this issue.
First, check if your plugin is blacklisted by command gst-inspect-1.0 -b.
If your plugin show up here, that means it is really blacklisted.
In that case, delete directory ~/.cache/ and then run gst-inpect-1.0 again.
This will force GStreamer to re-scan plugins list. If the reason of blacklist is not solved yet, gst-inpect will probably print out the reason here for you.
Another possible reason (but unlikely happens) is setting GST_REGISTRY_UPDATE as no, which will force GStreamer NOT to rescan the plugin directory, thus not found new plugin
P/s: The guide is for GStreamer 1.0
If you've tried removing your plugin from the blacklist and it still doesn't show up, try this:
export GST_PLUGIN_PATH=/usr/local/lib/gstreamer-1.0
/usr/local/lib/gstreamer-1.0 is the default directory used by make in case of plugins. If you have defined a different directory, use it.
Then run gst-inspect-1.0 and you'll find the newly compiled and installed plugin.
You'll be required to perform the export every time in the shell whether you either create a static pipeline with gst-launch-1.0 or run code of your own. I couldn't find any alternative to make it permanent other than making entry of this in .bashrc file. If you have one, please suggest via comments.
If you run ./configure --help in the gst-plugin directory you will see the following:
By default, make install' will install all the files in
/usr/local/bin', /usr/local/lib' etc. You can specify
an installation prefix other than/usr/local' using --prefix',
for instance--prefix=$HOME'.
If you do after the original installation:sudo updatedb && locate libgst[NAME_OF_YOUR_PLUGIN].so you should see where the library holding your plugin is located (in my case it is under /usr/local/lib/gstreamer-1.0/ as described by the configure help above).
Now on my machine, the GStreamer "official" plugins are installed under: /usr/lib/i386-linux-gnu/gstreamer-1.0/ . This is where the new created plugin library should be stored.
To store the plugin at the right place, run configure with the following parameter:
./configure --libdir=/usr/lib/i386-linux-gnu followed by make && sudo make install
It is important to override with --libdir and NOT --prefix! The usage of --prefix will stick a /lib that we don't want to have under /usr/lib/i386-linux-gnu.The plugin will not be found by gst-inspect-1.0 if /lib is added to the path.
Extra note :
Even if the plugin is at the proper location, you may still see GStreamer blacklisting it when you run gst-inspect-1.0. One of the cause of the blacklisting could be the shared library/ies required by your plugin not installed or not found on your platform. The ldd command can help figuring out the dependencies your plugin may have. Just run ldd [YOUR_GSTREAMER_LIBRARY].so
I'm building a script that will run on an EC2 instance that will automatically install our required packages and modules.
I'm having an issue with Perl module Lingua::LinkParser.
During compile it complains
LinkParser.xs:5:27: error: link-includes.h: No such file or directory
On Ubuntu link-includes.h is provided by package link-grammar and is installed in /usr/include/link-grammar/.
However Lingua::LinkParser's Makefile.PL is hard-coded(?) to look in /usr/local/include/link-grammar/.
Is there simple-ish way to resolve this issue?
Distroprefs
Best practice for using slightly modifying module from CPAN?
Install Perl modules that require customized options via CPAN
mob's suggestion above to just symlink /usr/include/link-grammar to /usr/local/include/link-grammar is the simplest way of handling this situation and this is what I'll use.
I have already installed Perl and libcurl using Cygwin's package manager. Now, I'm trying to install WWW::Curl. I have to specify the cURL include directory in WWW::Curl's Makefile.PL, but I have no idea where to look for this. Thanks for your time.
It will try to guess automatically. If it does not work, see the README.
P.S. LWP is more convenient to use.
edit: Using your package managers own packages is often preferred when using your system perl, cygwin has a package for perl-WWW-Curl, install this package rather than building your own.
Most likely I think you are missing the libcurl-devel package. Although you mention that libcurl is installed, please ensure that libcurl-devel is installed via the cygwin package management application, and try again if required.
WWW:Curl will search for the correct include path, looking for curl/curl.h, if it cannot find the file then it might be looking in the wrong places, you'll have to do a manual install:
download and unpack the package from cpan
read the included README file to understand this process
search your cygwin installation for a file called curl/curl.h note the directory that it is in.
modify the Makefile.PL so that #includes has the directory noted above included.
run perl Makefile.PL
run make && make install
This process is essentially the same problem as the process for a native Win32/strawberry perl install, in that it doesnt know where libcurl is located. you can check the README.Win32 file for similar instructions.
The libcurl-devel package installs the curl/curl.h file to usr/include/ which is a path that is already searched by Makefile.PL.
To however you say you have no idea where to look, locate the curl.h you can do the following:
find / -name curl.h
But be warned this could take a long time, you could try specific locations such as /usr
find /usr -name curl.h
Or even better you can look at the package contents to find the file location:
https://cygwin.com/cgi-bin2/package-cat.cgi?file=x86%2Flibcurl-devel%2Flibcurl-devel-7.41.0-1&grep=libcurl
To echo Alexandr's answer, LWP is more convenient to use cross platform, while covering the same features, it can also do a lot more.
I'm an absolute beginner at Perl, and am trying to use some non-core modules on my shared Linux web host. I have no command line access, only FTP.
Host admins will consider installing modules on request, but the ones I want to use are updated frequently (DateTime::TimeZone for example), and I'd prefer to have control over exactly which version I'm using.
By experimentation, I've found some modules can be installed by copying files from the module's lib directory to a directory on the host, and using
use lib "local_path";
in my script, i.e. no compiling is required to install (DateTime and DateTime::TimeZone again).
How can I tell whether this is the case for a particular module? I realise I'll have to resolve dependencies myself.
Additionally: if I wanted to be able to install any module, including those which require compiling, what would I be looking for in terms of hosting?
I'm guessing at the moment I share a VM with several others and the minimum provision I'd need would be a dedicated VM with shell access?
See perldoc perlxs.
You can probably inspect the module's source for DynaLoader or something like this. This way you can find out if a module uses any C code.
If you use a unix-like OS, you can use a package manager to see what files/libraries a package (perl module) installs.
You can use
use lib "your_local_path" ,
In this case , you can have module in your local path.