As a follow-up of this question, I started building MPICH2 from source. I found this tutorial: Installing MPICH2 on a Single Machine and so far what I did is this:
./configure --disable-f77 --disable-fc --disable-fortran
[seems to be OK]
make; sudo make install
[long output with one warning]
libtool: warning: relinking 'lib/libmpicxx.la'
root#pythagoras:/home/gsamaras/mpich-3.1.4# mpich2version
bash: mpich2version: command not found
What am I doing wrong? Notice that I had first installed MPICH2 with apt-get and in order to remove it, I did:
apt-get remove --purge mpich2
apt-get autoremove // which might removed something that I need now
Tomorrow, I am going to try this: Getting And Building MPICH (which with first attempt failed to work in the autogen.sh part).
EDIT_1:
I couldn't get it to work, will try a combination of the two tutorials and report back. I did a configure and then the make from the other tutorial, failed too.
EDIT_2
This may shade some light about where it got installed (by following the first tutorial):
root#pythagoras:/home/gsamaras/mpich-3.1.4# which mpiexec
/usr/local/bin/mpiexec
root#pythagoras:/home/gsamaras/mpich-3.1.4# which mpirun
/usr/local/bin/mpirun
You installed into /usr/local, which is an OK way to do things. The README instructions you followed suggests another way which will not require administrative privileges.
I like to install into /home/robl/soft/mpich-whatever , so I can have different compilers, versions, configurations, etc. such flexibility is probably overkill for you, but it's one strategy.
To your question:
root#pythagoras:/home/gsamaras/mpich-3.1.4# mpich2version
bash: mpich2version: command not found
First, the command is now mpichversion, not mpich2version -- it's possible you were following an old tutorial.
Second, your shell might not know about the newly installed binaries. hash -r (at least on bash and tcsh) will tell the shell "forget about what you think you know about my file system and look harder".
I found this mpich-3.0.4-README, who seems to provided the solution.
Long story short, it says (it assumes you want to build 3.0.4 version, I did it with 3.1.4 (available here)):
tar xzf mpich-3.0.4.tar.gz
cd mpich-3.0.4
// you might want to disable fortran compiler (see the README I linked above)
./configure --prefix=/home/<USERNAME>/mpich-install 2>&1 | tee c.txt
make 2>&1 | tee m.txt
make install 2>&1 | tee mi.txt
PATH=/home/<USERNAME>/mpich-install/bin:$PATH ; export PATH
which mpicc
// should return something reasonable (with your directory)
mpiexec -n 2 ./examples/cpi
Now, the option with the machinefile does not work, because ssh needs a password, but that's another question.
Related
I am trying to install kaldi on a windows computer using cygwin.
When I run ./tools/check_dependencies.sh (as requested in the INSTALL file)
I get "zlib is not installed", so I go to the cygwin package list and try to install.
The thing is - there is no "zlib" per say see snapshot
there are all kinds of packages but their execution name is not "zlib" (except one which is irrelevant), it's always something-zlib-somthing.
And so I end up getting the same message even after I install them.
The code in check_dependencies.sh that does that is:
if ! echo "#include " | $CXX -E - >&/dev/null; then
echo "$0: zlib is not installed."
add_packages zlib-devel zlib1g-dev zlib-devel
fi
I understood there is no (relevant) way of installing zlib directly with cygwin - so that's a dead end.
Anyway I tried to make it work but no success - your help is very much appreciated.
Using Kaldi in cygwin is originally a bad idea. Its kind of supported but you will have many problems here and there. Simply install Linux either on a separate server or in a virtual machine.
Good afternoon,
I was able to build my project into a deb package using:
fakeroot dpkg-deb --build mypackage
Next, I can install the package using
dpkg -i mypackage.deb
Everything is installed and copied correctly when I do this, however I would like to run a few bash commands after the package is installed.
I understand this needs to be done using the postinst file in the mypackage/DEBIAN directory
I have seen a few examples of this script online, but no clear explanation of how to write one and how to include it in the build.
How do I make sure fakeroot dpkg-deb includes this script, is placing it into DEBIAN directory enough?
There is a case structure in the postinst script, what is this for, and where do I place the bash commands to execute in that script
If I install the package with dpkg - i mypackage.deb is this enough to run that script?
An example script I would like to make is shown below.
What do "configure, abort-upgrade, abort-remove, and abort-deconfigure" stand for.
What does the "update-alternatives" line do.
Thank you for your help,
postinst file below.
#!/bin/sh
set -e
case "$1" in
configure)
# EXECUTE MY BASH COMMAND
echo /usr/local/lib > /etc/ld.so.conf && ldconfig
;;
abort-upgrade|abort-remove|abort-deconfigure)
exit 0
;;
*)
echo "postinst called with unknown argument \`$1'" >&2
exit 1
;;
esac
update-alternatives --install /usr/bin/fakeroot fakeroot /usr/bin/fakeroot-ng 5 \
--slave /usr/share/man/man1/fakeroot.1.gz \
fakeroot.1.gz /usr/share/man/man1/fakeroot-ng.1.gz
exit 0
First, here is possibly the most relevant documentation: Debian Policy Manual: Package Maintainer Scripts and Installation Procedure.
Second, the very most important thing to remember when writing or dealing with maintainer scripts is that they must be idempotent. Assume the script will be run many times in succession, and make sure things still won't break if so.
To answer your questions directly,
Putting it in the DEBIAN directory is correct, when building with dpkg-deb. If you were instead using Debhelper for a safer or more convenient build setup, you might put the postinst in debian/$packagename.postinst.
The postinst script can be called in a number of different situations. The "case" statement you can find in many (most?) postinsts is meant to check which situation it is. Generally speaking, it makes sense to take most postinst actions in all of the possible situations, and that's why they are grouped together in one script. But sometimes it is better to differentiate. I'll explain the different scenarios under #4.
Yes. A successful installation of a deb package (whether by dpkg -i, apt-get install, or whatever) must involve a successful run of its preinst and postinst scripts, if present. It is possible to "unpack" a deb without running any maintainer scripts, but that is not considered "installing".
These "action" names correspond to the different situations in which a postinst can be run.
configure: A package is being installed or upgraded. If the package wasn't installed before, $2 will be empty. Otherwise $2 will contain the old version number of the package; the version from which you are upgrading.
abort-upgrade: An upgrade operation was aborted. As an example, I have version V1 of mypkg installed, and I try to upgrade it to V2. But the preinst or postinst of V1 fail to run successfully, or there is a file conflict. dpkg stops trying to install V2, and re-runs the postinst from V1 (with the "abort-upgrade" action) in case any state needs to be restored.
abort-remove: A remove operation was aborted. For example, if I ran "dpkg -P mypkg", but mypkg's prerm script failed to run, or something else happened that made dpkg think it could not safly uninstall mypkg. So it runs mypkg's postinst again (with the "abort-remove" action) in case any state needs to be restored.
abort-deconfigure: As you might guess, a deconfigure operation was aborted. "deconfiguring" is sort of a half-removal action used when a package being installed conflicts with others already installed. To make the explanation short, if the abort-deconfigure action is being run, the postinst is expected to restore any state that might have been undone by the prerm script with the deconfigure action.
For lots of additional nitty-gritty details, see the great charts and explanations at https://people.debian.org/~srivasta/MaintainerScripts.html .
The "update-alternatives" command updates entries in the Debian "alternatives" system. See the man page. In this specific case, the command is telling Debian that "/usr/bin/fakeroot-ng" is an alternative for the fakeroot command. Depending on the priority of this alternative and the priority of other registered alternatives, and the preference of the user, fakeroot-ng might now be invoked when someone runs "fakeroot".
Just one think about this line :
echo /usr/local/lib > /etc/ld.so.conf && ldconfig
According the Debian Policy, you shouldn't modify ld.so.conf
A simple alternative is to do something like that :
In your postinst script :
/usr/local/lib > /etc/ld.so.conf.d/EXAMPLE.conf && ldconfig
and in your postrm script :
rm /etc/ld.so.conf.d/EXAMPLE.conf && ldconfig
I tried to upgrade Perl and put my computer into a complete mess
I am currently running RHEL6.5, 64bits, and this is the thing:
I had perl-5.10.1 installed, and working nice. this came installed,
and I could see it from yum
I wanted to install Padre, an Perl IDE, but that required at least v5.11 [I was so close! :( ]
There were no newer version for Perl in the repos that I have access to (and I have a limitation that I can't add new repos)
I got approval from my boss to download perl-5.20 .0 from www.perl.org and tried to install it
... and the mess begins!
First I installed the new perl with my own id, and that pushed perl to somewhere under my home dir
I tested with 'perl -v' and could see that my env was pointing to the newer install, however, yum never recognized it (not really a problem)
When I tried to install Padre, seems somehow it had the hardcoded the original perl (from /usr/bin) and still claiming for something as newer as 5.11.
Trying to fix it, I did installed the new perl again, now using root, to make it push perl under /usr tree ... it installed, but pushed perl to /usr/local/bin, instead of /usr/bin
So again, I had one more perl install but Padre still looking for the one on /usr/bin
I give up about Padre, and deleted the files related to it, as well as the perl installed on my home dir, however a couple of perl scripts that I had already coded now are throwing errors like:
perl -cw "xmltest.pl" (in directory: /home/myid/scripts/xmltest.pl)
perl: symbol lookup error: /usr/lib64/perl5/auto/Data/Dumper/Dumper.so: undefined symbol: Perl_Istack_sp_ptr
Compilation failed.
... and Data::Dumper in not the only one ... every time I disable one of the modules, another one hangs in the same, or similar way
From what I read about this, seems that this issue is related to modules that were originally installed for one perl version, and are being called by another, however, I already forced the modules that I use to be reinstalled directly from CPAN, and they still failing
Question: How can I, safely, get free from this current perl installs, and perform a new clean install be able to use it w/o these versions conflicts?
My major concern are about the numerous apps that I have that depends on Perl, and I my not broke then on a uninstall
Any help will be much appreciate.
You should:
cleanup
clean (comment out) your ~/.profile from any unwanted paths, and so on
clean any new perl installation from your $HOME (move to safe place for sure)
in short, try return your environment into previous working state
relog, (logout, login)
repair your system perl. Thats mean,
read #Sam Varshavchik's answer
reinstall it from your distribution, using your package manager (5.10).
this step should overwrite the mess you caused.
test it !
don't continue until youre ensured, everything working right as before.
Lesson learned: never overwrite your system perl
learning
read thru perlbrew.pl
repeat previous step once again, especially with the
the homepage
http://perlbrew.pl/Perlbrew-and-Friends.html
https://metacpan.org/pod/App::perlbrew
https://metacpan.org/pod/perlbrew
installing perlbrew
run the installation command \wget -O - http://install.perlbrew.pl | bash
should finished without errors
follow the instructions how to modify your startup file e.g. ~/.profile or such... (you need to add one line to the end)
check your ~/perl5/perlbrew/bin should contain prelbrew and patchperl
relog
setup new perl, run
perlbrew init #init environment
perlbrew available #show what perl you can install
perlbrew install 5.20.0 #will take few minutes - depends on your system speed
perlbrew install-cpanm
perlbrew list #check
perlbrew switch perl-5.20.0 #activate newly installed perl 5.20
Check your installation
in the ~/perl5/perlbrew/bin you should have 3 scripts: prelbrew , patchperl , cpanm
perl -v should return 5.20
type cpanm - should return ~/perl5/perlbrew/bin/cpanm
You're done.
CPAN modules
You can install new modules with cpanm, like:
applications
cpanm cpan-outdated
cpanm App::Ack
cpanm Unicode::Tussle
cpanm Perl::Tidy
cpanm Perl::Critic
collections
cpanm Task::Moose
cpanm Task::Plack
cpanm Task::Unicode
modules
cpanm Path::Tiny
cpanm Try::Tiny
cpanm JSON
cpanm YAML
etc...
Check the ~/perl5/perlbrew/perls/perl-5.20.0/bin/ for new commands
You will need update your own perl script's shebang line to
#!/usr/bin/env perl
I hope don't forget anything, maybe other more experienced perl-gurus will add/edit/correct more.
Anyway, in the reality the steps 5,6,7 are much easier as sounds (by reading this) and could be done in few minutes.
On rpm-based Linux distributions, you should never install system software manually, like this, by trying to compile and build it yourself. RHEL's package management tool, rpm, performs an important function of keeping track of dependencies between packages, and prevent package conflicts.
The errors you showed are precisely the symptoms of a corrupted system Perl installation, and rpm exists precisely to avoid this sort of thing happening. Manually building and installing random tarballs completely bypasses the safety net that rpm provides.
There's no cookie-cutter recipe for recovering from a corrupted system install of a critical system rpm like perl, but in general:
1) run "rpm -q" perl, this will show you the exact version of the perl rpm package that rpm thinks should be installed.
2) go to the RHEL installation media/directory, verify that it contains the same perl-.x86_64.rpm package. If you previously installed RHEL updates, it's possible that you already updated perl, so look for the version that rpm tells you have installed in the RHEL update directory, and verify that you have the correct rpm package.
3) Execute:
rpm -ivh --force perl-<version>.x86_64.rpm
This will reinstall the original perl RPM package that was previously installed. Your problem is not only that you have extra versions of perl installed, but that it's likely that some of your custom perl builds have clobbered the system perl package, and uninstalling them won't help, you have to reinstall the system perl.
4) In RHEL, many perl modules are installed as separate packages. The above process should be used to reinstall every perl rpm package that you have installed. Execute:
rpm -q -a | grep '^perl'
This will give you a list of all Perl packages you have installed. You will need to repeat this procedure for every Perl rpm package.
It's not a 100% guarantee that this will fix everything, there could be other things wrong too, but this is a good first step towards recovery.
What I have done:
From #Sam-Varshavchik answer:
Found the previous perl rpm in my yum cache, and installed ...
rpm -ivh --force perl-<version>.x86_64.rpm
Checked for others "perl*" previously installed packages ... there were +260 so saved it in a file rpm -qa "perl*" > /tmp/perl.pkgs
With +260 packages to install, I realized that do it manually would take too much time, so it was time to put some ksh skills in practice ...
I checked at my yum cache and found ~130 of the +260 packages, so
took out from the list the base perl package (that I already have installed);
for those in the cache, I decided to install then with rpm, in the same way as the base package;
for those that I did not have handy, I used yum, which would download and do the same
of rpm, so ...
CACHE="/var/cache/yum/x86_64"
for perlpkg in $(cat /tmp/perl.pkgs)
do
FILE=$(find $CACHE -name "${perlpkg}.rpm")
if [[ ${FILE} != "" ]] ; then
rpm -ivh --force ${FILE}
else
yum -y reinstall ${perlpkg}
fi
done
From #jm666:
Installed perlbrew (was able to got it from my auth repos, so got it using yum) and using perlbrew, installed 5.20.0 localy
TODO: Didn't got any additional modules and neither Padre yet ... need to learn more about the way perlbrew works and isolate the installed version away from the system perl
Once again, thanks #Sam-Varshavchik and #jm666 for your support ang guidance
I want to test rna-star code. I have Ubuntu 12.04 on my machine.I have downloaded all the packages necessary:
sudo apt-get update
sudo apt-get install g++
sudo apt-get install make
But in the installation step I have problem running make command on STAR executable file.on the installation manual I see it says:
Unzip/tar STAR_x.x.x.tgz file into a directory of your choice <
STARsource >, cd < STARsource > and run make. The source code will be
compiled and the STAR executable will be generated.
when I run 'make STAR' it says:
make: Nothing to be done for `STAR'.
any suggestion?
This means that the "STAR" target does not exist. In a makefile, you define targets (implicit or explicit) and make takes care of building in the correct orders the dependencies for your target.
You should read documentation on this project or glance at the makefile : it's likely you need to run "make" without parameters (which is stated in your documentation excerpt), something like :
tar zxvf star...tgz
cd star...
make
So I just ran into the same problem.
Apparently the following solved it:
Redirect to source map: cd STAR-2.5.3a/source
The Makefile is in this location, after this just enter the command make.
It should start running. If you work in a cluster do not forget to edit your shell configuration before using;
export PATH=$HOME/STAR-2.5.3a/source:$PATH
I am trying to install mpich-3.1 in a linux cluster (Ubuntu 12.04 running on all machines). Previously I installed mpich2 by sudo apt-get install mpich2 but couldn't find how to run tests. Then I removed with sudo apt-get remove mpich2.
So I decided to upgrade to 3.1. I downloaded and installed mpich following instructions at https://www.mpich.org/static/downloads/3.1/mpich-3.1-installguide.pdf by running:
sudo ./configure -prefix=/usr/local/mpich/
sudo make
sudo make install
and apparently is properly installed. If I run
meteo#ventus:~/RAMS/RUN$ /usr/local/mpich/bin/mpiexec -f machinefile -n 20 hostname
ventus
ventus
ventus
ventus
ventus4
ventus4
ventus4
ventus4
ventus5
ventus5
ventus5
ventus5
ventus2
ventus2
ventus2
ventus2
ventus3
ventus3
ventus3
ventus3
Although I find it is responding "slowly". Where machinefile is
ventus:4
ventus2:4
ventus3:4
ventus4:4
ventus5:4
The directory is exported to all nodes in the cluster, /etc/exports
/usr/local/mpich 192.168.1.0/24(rw,sync)
In /etc/mtab ant /etc/fstab in node ventus4
ventus:/usr/local/mpich /usr/local/mpich nfs rw,vers=4,addr=192.168.1.1,clientaddr=192.168.1.4 0 0
ventus:/usr/local/mpich /usr/local/mpich nfs
Maybe the problem comes from a prior install not completely removed
meteo#ventus:~$ which mpiexec
/usr/local/bin/mpiexec
meteo#ventus:~$ which mpirun
/usr/local/bin/mpirun
meteo#ventus:~$ which mpicc
/usr/local/bin/mpicc
Following installation instructions which mpiexec should point to mpich installation bin directory /usr/local/mpich/bin/mpiexec
But if I move /usr/local/bin/mpiexec to /usr/local/bin/mpiexec.old
then
meteo#ventus:~$ which mpiexec
/usr/local/mpich/bin/mpiexec
points to my new mpich3 install directory. Could this be the reason of that slow performance? Which test should I run for benchmarking? How do I completely remove mpich2.
If you do in fact have root access to your entire machine, then you can always just delete all of the binaries, libraries, headers, etc. I'm not sure where everything is installed on your system (it's different everywhere), but the usual locations are /usr/local/bin, /usr/local/include, /usr/local/lib, etc. You should look for these files (or things that look similar:
bin/:
Anything that starts with mpi
include/:
Anything that starts with mpi
Anything that starts with opa
lib/:
Anything that includes mpich
Anything that includes mpl
Anything that includes opa
Beyond that, there's not much that would interfere (there's man pages somewhere too, but that's fine). If you delete all of those files, you should have gotten rid of your MPICH2 installation. This really should have been cleaned up with you did your apt-get uninstall, but that's neither here nor there...
Now, to test your new MPICH installation (the project is called MPICH now, not MPICH3), there are lots of MPI benchmarks. I'd suggest typing mpi benchmarks into your favorite search engine any trying out a few of the ones that you find. If you want to compare, you can install a few different versions of MPI. When you do this, make sure you are correctly setting up your PATH and LD_LIBRARY_PATH environment variables so your installations can sit side by side.