I've got a perl module (Email::AutoReply) which has BerkeleyDB listed in the README as an optional dependency. When you try to install it with cpan or cpanminus, it tries to install BerkeleyDB as well. The problem is that no matter what I do, BerkeleyDB fails to install with a long list of errors, even though I meet all the requirements. This is preventing me from installing Email::AutoReply, even though it's supposed to be an optional thing.
So, how do I install a module without one of it's dependencies? Can I remove the dependency somehow? Is there some command line option for this?
After installing the other dependencies (which you probably have done from your earlier attempts),
cd /tmp
wget http://search.cpan.org/CPAN/authors/id/A/AM/AMONSEN/Email-AutoReply-1.04.tar.gz
tar xvzf Email-AutoReply-1.04.tar.gz
cd Email-AutoReply
perl Makefile.PL && make test && make install
cd ..
rm -rf Email-AutoReply
Related
I've freshly installed Ubuntu 18.04 and have decided to try Anaconda. However, when I then try to install Mendeley, I get the following error:
mendeleydesktop depends on python; however:
Package python is not installed.
I assume the issue here is that python is now in ~\anaconda2\bin, instead of \usr\bin. I'm not certain what I should do. As I see it, I have 3 options:
Install a system python into \usr\bin, but this seems sloppy/messy
Put a softlink in \usr\bin along the lines of ln -s python ~\anaconda2\bin\python, but I'm worried that there might be implications to that, which I don't understand
Somehow tell the mendeley.deb file where the python I'm using is, but I don't know how to do this.
Are either 1 or 2 reasonable options? If not how do I implement my 3rd option, or what else should I do?
Empirically found option 2 does not work. dpkg is still looking for the installation of the python package
You can use the method given here to remove the system python dependency in the .deb file; I tried this and mendeley seems to install as normal. Assuming your conda environment is set up correctly, it will work. I had to modify the instructions on that page slightly:
Unpack deb: $ ar x mendeleydesktop_1.19.4-stable_amd64.deb (will create i.e. three files: debian-binary control.tar.gz data.tar.gz)
Unpack control archive: $ tar xzf control.tar.gz (will create: postinst control)
Fix dependencies in control (use a text editor)
Repack control.tar.gz: $ tar c postinst control | gzip -c > control.tar.gz
Repack deb: $ ar rcs mendeleydesktop_1.19.4-stable_amd64_nopythondep.deb debian-binary control.tar.gz data.tar.gz (order important! dpkg wouldn't be able to read the metadata of a package quickly if it had to search for where the data section ended!)
I have two systems that use the same command line interface written in ruby. One system is using an older version that's incompatible with the scripts we have written. We'd like to use bundler to download all the dependencies for the 2.0 on our own system, and then migrate that bundle over to the system with the older version so that we can use 2.0 there as well.
We do not have the option to run bundle install on the other system because it's not open to the internets.
So the idea is on my system:
bundle init
...write Gemfile...
bundle install
tar -czf cli2.0.tar.gz ./Gemfile ./Gemfile.lock ./.bundle ./bundle
... move cli2.0.tar.gz to the other system ...
On system B:
tar -zxf cli2.0.tar.gz
bundle exec cli2.0 version
But at this point we get an error stating that bundler couldn't find any of the gems even though they're right there under ./bundle/ruby/2.3.0/!!
It looks like they have different versions of ruby, and ruby-gems installed.
Received some help from a coworker, the gist is I was doing it all wrong.
If you want to transport gems and see consistent performance with bundler do this.
bundle install <gem>
bundle package
This creates a cache of the downloaded gems for transport.
tar -czf ./transport.tar.gz ./Gemfile ./Gemfile.lock ./vendor
On the next machine:
tar -xzf ./transport.tar.gz
bundle exec <command>
Might be worth a try to make your second Gemfile (the one without internet access) reference the gems using paths.
i.e.
gem some_gem, path: "/home/you/some_path/some_gem"
See this question for more info on that.
If you don't have internet access but can transfer over files, it might be worth transferring the source code for a new version of bundler/RubyGems as well.
I'm trying to get biotools working on my Mac so that I can run some Perl5 code that uses Bio::DB::Sam, but am stymied.
Mac OS X 10.10.4
perl 5.18.2
upgraded CPAN as per INSTALL instructions
'brew install expat' tells me that expat-2.1.0_1 is already installed
'sudo perl -MCPAN -e shell'
'install CJFIELDS/BioPerl-1.6.924.tar.gz'
'Do you want to run the Bio::DB::GFF or Bio::DB::SeqFeature::Store live database tests?' => 'n'
Install all
'Do you want to run tests that require connection to servers across the internet' => 'n'
Eventually get (with some lines deleted):
Running Build test
t/Align/AlignStats.t ................... ok
t/Align/AlignUtil.t .................... ok
t/Align/Graphics.t ..................... skipped: The optional module GD (or dependencies thereof) was not installed
...
t/AlignIO/msf.t ........................ ok
t/AlignIO/nexml.t ...................... skipped: The optional module Bio::Phylo (or dependencies thereof) was not installed
t/AlignIO/nexus.t ...................... ok
...
t/Assembly/ContigSpectrum.t ............ ok
t/Assembly/IO/bowtie.t ................. skipped: The optional module Bio::DB::Sam (or dependencies thereof) was not installed
t/Assembly/IO/sam.t .................... skipped: The optional module Bio::DB::Sam (or dependencies thereof) was not installed
t/Assembly/core.t ...................... ok
t/Cluster/UniGene.t .................... ok
Afterwards, I test with:
perl -e "use Bio::DB::Sam;"
and get:
Can't locate Bio/DB/Sam.pm in #INC (you may need to install the Bio::DB::Sam module) (#INC contains: /Library/Perl/5.18/darwin-thread-multi-2level /Library/Perl/5.18 /Network/Library/Perl/5.18/darwin-thread-multi-2level /Network/Library/Perl/5.18 /Library/Perl/Updates/5.18.2/darwin-thread-multi-2level /Library/Perl/Updates/5.18.2 /System/Library/Perl/5.18/darwin-thread-multi-2level /System/Library/Perl/5.18 /System/Library/Perl/Extras/5.18/darwin-thread-multi-2level /System/Library/Perl/Extras/5.18 .) at -e line 1.
BEGIN failed--compilation aborted at -e line 1.
I get the same results when cloning bioperl-live from GitHub (sync'd to revision 73c446c69a77) and trying to install that way.
Note that I have installed samtools 0.1.18 (to match the version on our cluster) by:
downloading the .tar.gz
running 'make'
copying 'samtools', 'bcftools/bcftools', and 'misc/*.pl' to ~/debarcer-packages/bin, which is on my path
Afterward, I get this:
$ which samtools
/Users/gvwilson/debarcer-packages/bin/samtools
This build did not produce a '.so' file, even though there is a rule in the samtools-0.1.18 Makefile that looks like it (maybe?) ought to produce one.
The module Bio::DB::Sam provides bindings to an older version of samtools that did not rely htslib. This is an important point because you may run into issues using SAM/BAM files generated with samtools or other aligners because most tools use htslib these days.
For building the module, you are on the right track with the version you are using but it is difficult to build if you do not know the correct flags. I previously provided a solution to do this and I'll show a better way here (just use a package manager for the Perl module).
wget http://sourceforge.net/projects/samtools/files/samtools/0.1.18/samtools-0.1.18.tar.bz2
tar xjf samtools-0.1.18.tar.bz2 && cd samtools-0.1.18
make CFLAGS=-fPIC
export SAMTOOLS=`pwd`
The last command will allow you to install the Perl module without looking for the PATH to samtools and being prompted for it. Note, the extra CFLAGS argument may not be needed on your Mac, so try without it first. It is required on Linux, and since the module uses so much memory you will likely only be using this on a Linux machine. Now, install the Perl module.
cpanm Bio::DB::Sam
or cpan if you prefer. That should get you a working Bio::DB::Sam. I don't know what you are trying to do but I will mention that the fine folks over at EBI have developed bindings to htslib called Bio::DB::HTS based on Lincoln Stein's XS code in the Bio::DB::Sam module. This is really what you should be using because the version of SAMtools mentioned above is really old and not being developed. That is my opinion and a word of caution though, nothing wrong with Bio::DB::Sam.
edit:
You find it easier to manage Perl without using the "system" Perl, and here is one solution. Other people may have their preferred method, but perlbrew (combined with cpanminus) will make this type of work fun and much less of a pain (and they are popular choices). That would be my first step: set up perlbrew, install Perl 5.22, then install cpanminus. That might sound challenging but it is just a few commands. Something along the lines of:
curl -L http://install.perlbrew.pl | bash
source ~/perl5/perlbrew/etc/bashrc
perlbrew install perl-5.22.1
perlbrew switch perl-5.22.1
perlbrew install-cpanm
should do the trick. That will give you a kick-ass Perl with some nice features not available with your "system" Perl. This is a good idea because using /usr/bin/perl requires sudo, it involves messing with the system libraries which might cause an issue, and the recent Apple changes mean that working with root directories/libraries is completely unstable.
You need to install an additional (optional) module to use samtools. That's what the The optional module Bio::DB::Sam message is about. You don't need it for the rest of BioPerl, so it's not a hard dependency.
For Bio::DB::Sam, you need samtools-0.1.17 (the latest version the module works with according to its docs). I downloaded the source and ran make. There were some warnings, but it appears to work. From your question, I don't think you had a problem here.
I then installed Bio::DB::Sam:
$ cpan Bio::DB::Sam
There were some compiler warnings, but the module passed its tests and installed. The cpan command took care of dependencies too, so it also installed BioPerl for me.
If you need some environment variables, you can set them for a one-off run of the command:
$ CFLAGS=... SAMTOOLS=... cpan Bio::DB::Sam
Note that installing Bio::DB::Sam prompted me for the location of samtools. I pointed it at the build directory:
$ cpan5.22.0 Bio::DB::Sam
Running install for module 'Bio::DB::Sam'
Configuring L/LD/LDS/Bio-SamTools-1.43.tar.gz with Build.PL
This module requires samtools 0.1.10 or higher (samtools.sourceforge.net).
Please enter the location of the bam.h and compiled libbam.a files: /Users/brian/Downloads/samtools-0.1.17
I'm betting there's not something complicated like the answer SES gave. You just need an optional module. The README for Bio::DB::Sam notes some problems that people might have and offers so workarounds, but I didn't run into these problems and my setup is close to yours.
Note that Alien::SamTools is a Perl package that installs the non-Perl samtools, but it says it installs 0.1.19. Maybe that works too, but that's not what Bio::DB::Sam says on the tin.
I have a problem installing package dionaea.
After I type this:
./configure --with-lcfg-include=/opt/dionaea/include/ \
--with-lcfg-lib=/opt/dionaea/lib/ \
--with-python=/opt/dionaea/bin/python3.1 \
--with-cython-dir=/usr/bin \
--with-udns-include=/opt/dionaea/include/ \
--with-udns-lib=/opt/dionaea/lib/ \
--with-emu-include=/opt/dionaea/include/ \
--with-emu-lib=/opt/dionaea/lib/ \
--with-gc-include=/usr/include/gc \
--with-ev-include=/opt/dionaea/include \
--with-ev-lib=/opt/dionaea/lib \
--with-nl-include=/opt/dionaea/include \
--with-nl-lib=/opt/dionaea/lib/ \
--with-curl-config=/opt/dionaea/bin/ \
--with-pcap-include=/opt/dionaea/include \
--with-pcap-lib=/opt/dionaea/lib/ \
--with-glib=/opt/dionaea
and the next step is:
#make
An error message appears:
make: *** No targets specified and no makefile found. Stop.
My directory is /usr/local/src
make takes a makefile as input. Makefile usually is named makefile or Makefile. The configure command should generate a makefile, so that make could be in turn executed. Check if a makefile has been generated under your working directory.
running ./configure should solve your problem.
I got the same error and i fixed it by looking at the solution from this site:
http://trac.macports.org/ticket/40476.
SO did you got any error after running './configure' ? Maybe something about lacking tclConfig.sh.
If so, instead of running './configure', you have to search for the tclConfigure.sh first and then put it in the command, in my case, its located in /usr/lib/. And then run:
'./configure ----with-tcl=/usr/lib --with-tclinclude=/usr/include'
./configure command should generate a makefile, named makefile or Makefile. if in the directory there is no this file, you should check whether the configure command execute success.
in my case, I configure the apr-util:
./configure --prefix=/usr/local/apr-util --with-apr=/usr/local/apr/bin/apr-1-config
because the --with-apr=/usr/local/apr/bin/apr-1-config, the apr did not install yet, so there configure fail, there did not generate the apr's /usr/local/apr/bin/apr-1-config.
So I install the apr, then configure the apr-util, it works.
You had to have something like this:
"configure: error: "Error: libcrypto required."
after your ./configure runs. So you need to resolve noticed dependencies first and then try ./configure once more time and then run make !
I recently ran into this problem while trying to do a manual install of texane's open-source STLink utility on Ubuntu. The solution was, oddly enough,
make clean
make
If after ./configure Makefile.in and Makefile.am are generated and make fail (by showing this following make: *** No targets specified and no makefile found. Stop.) so there is something not configured well, to solve it, first run "autoconf" commande to solve wrong configuration then re-run "./configure" commande and finally "make"
Delete your source tree that was gunzipped or gzipped and extracted to folder and reextract again. Supply your options again
./configure --with-option=/path/etc ...
Then if all libs are present, your make should succeed.
This may happen if there is any read and write permission denial to the user. Like C:\Windows\System32\ have restricted access and you are cloned and trying to make from such restricted directory.
If you create Makefile in the VSCode, your makefile doesnt run. I don't know the cause of this issue. Maybe the configuration of the file is not added to system. But I solved this way. delete created makefile, then go to project directory and right click mouse later create a file and named Makefile. After fill the Makefile and run it. It will work.
Try
make clean
./configure --with-option=/path/etc
make && make install
In my case there was a file Makefile.PL in a database library:
http://www.cpan.org/modules/by-module/DBI/DBI-1.630.tar.gz
The following command created the makefile
perl Makefile.PL
After that, make command worked
I think that it can mean that ./configure command failed for some reason, in my case it was due to a missing package. So i have used my OS package manager to install required package (autoconf and autoconf-archive in my case), then it worked.
first time try
make clean
make
if these didn't solve your issue you have to install build packages.
debian base
apt-get install build-essential libgtk-3-dev
For RHEL/CentOS
sudo yum install gcc glibc glibc-common gd gd-devel -y
Step 1: Install the Required Dependencies
First, launch the Terminal and run the commands below to install the required dependencies and libraries.
sudo apt install autoconf automake libpcre3-dev libnl-3-dev libsqlite3-dev libssl-dev ethtool build-essential g++ libnl-genl-3-dev libgcrypt20-dev libtool python3-distutils
sudo apt install -y pkg-config
Step 2: Compile and Install
Now, run the commands below (one by one in order) to compile the source code and install Your Repo on your system.
[Before this enter you directory ex: cd folder_name]
sudo autoreconf -i
sudo ./configure --with-experimental --with-ext-scripts
sudo make
sudo make install
I hope this time problem will be solved.
You need to check the output of the configure command.
Mine contained this error:
configure: error: in `/home/ubuntu/build/php-8.0.19':
configure: error: The pkg-config script could not be found or is too old. Make sure it
is in your PATH or set the PKG_CONFIG environment variable to the full
path to pkg-config.
Then I googled the error and solved it.
Before running "make" you need to configure your build using "CMake"
Try:
cmake .
Creating Makefile in the VScode did not worked for me. So, delete the make file created in the VS code, go to the project directory and create file add all the commands in it and name it as Makefile and save. Then try to execute it in VS code. It will work. Don't know why it doesn't work with VS code.
Unpack the source from a working directory and cd into the file directory as root. Use the commands ./configure then make and make install
Is there a way to get a list of filenames/paths that make install copies to the filesystem? Some packages come with a MANIFEST file, but not the ones that I am working with.
I was just investigating this myself while compiling a custom version of QEMU. I used the following method to work out what was installed and where (as well as using it as a basis for a .deb file):
mkdir /tmp/installer
./configure --target-list=i386-softmmu
make
sudo make install DESTDIR=/tmp/installer
cd /tmp/installer
tree .
Tree is a utility that recursively displays the contents of a directory in a visually appealing manner - sudo apt-get install tree for Debian / Ubuntu users
Hope that helps someone... it took me a bit of poking around to nut it out, but I found it quite a useful way of visualising what was going on.
The most fool-proof way is to use chroot: have "make install" run inside a chroot jail; compute a list of the files that you had before the installation, and compare that to the list of files after the installation.
Many installations will support either a --prefix configuration option, and/or a DESTDIR environment variable. You can use those for a lighter-wait version of chroot (trusting that the installation will fail if it tries to write to a location outside these if you run installation as a fairly unprivileged user).
Another approach is to replace the install program. Many packages support an INSTALL environment variable that, well, is the install program to use; there are tracing versions of install around.
make uninstall might show the files as it removes them if the author of the compiling instructions provides the information to allow an uninstall (it has been awhile since I have done one so I can't say for sure).
Also make -n install will do a "dry run" of the install process and it may be reasonable to extract the information from its results.
It differs for every project that you run 'make install' on. The files which are installed are controlled by the install target in the Makefile being used. Your best bet is to open the Makefile and search for 'install:' - from there you can see what files will be copied out to your system.
Take a snapshot of the contents of the install location before installing
Install
Compare the current contents with the old contents.
Example:
./configure --prefix /usr/local
make -j`nproc`
find /usr/local | sort -u > /tmp/snapshot1
make install
find /usr/local | sort -u > /tmp/snapshot2
comm -3 /tmp/snapshot{1,2} # this prints the files added by `make install` to stdout
If the install program you're using doesn't support DESTDIR or --prefix (or an equivalent), I have found that it may be possible to identify new files as follows:
Start with as clean a system as possible (a fresh VM image is preferable)
Compile the software, wait a few minutes.
Install the software package.
Find files modified within the past 5 minutes: sudo find / -mmin -5 -type f (the find command has a ton of parameters for querying based on file modification / creation times, but this worked pretty well for me; you just need to narrow the time span so that you pick up the files created by the installer but nothing else).