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
Related
First I install QScintilla by following steps:
1:
cd Qt4Qt5
qmake qscintilla.pro
sudo make
make install
2:
cd ../designer-Qt4Qt5
qmake designer.pro
sudo make
sudo make install
3:
cd ../Python
python3 configure.py --pyqt=PyQt5
sudo make
And here I met the problem :
QAbstractScrollArea: No such file or directory
and problem:
qprinter.h: No such file or directory
But I finally solved them by manually add required files.
Goes on:
sudo make install
4:
then I go to install eric6 by typing:
sudo python3 install.py
But I got:
Checking dependencies
Python Version: 3.4.0
Found PyQt5
Sorry, please install QScintilla2 and
its PyQt5/PyQt4 wrapper.
Error: /usr/lib/python3/dist-packages/PyQt5/Qsci.so: undefined symbol: _ZTI13QsciScintilla
The main problem is that you are linking against Qt4 rather than Qt5. This is why the QAbstractScrollArea and QPrinter headers are reported as missing, and why you later get the undefined symbol error.
QScintilla uses a features file to control compile-time configuration, and its sources need to be patched to get a good build for Qt5.
So first unpack a fresh set of sources, and then make these changes:
designer-Qt4Qt5/designer.pro:
TARGET = qscintillaplugin_qt5
Qt4Qt5/features/qscintilla2.prf:
} else {
LIBS += -lqscintilla2_qt5
}
}
} else {
LIBS += -lqscintilla2_qt5
}
Qt4Qt5/qscintilla.pro:
TARGET = qscintilla2_qt5
...
features.path = $$[QT_INSTALL_ARCHDATA]/mkspecs/features
This will ensure that you get independent qscintilla libs for Qt5.
With that done, take the following steps to build (as a normal user):
cd 'path/to/src/Qt4Qt5'
# this is essential for correct linking
export QMAKEFEATURES="$PWD/features"
# make sure you use the right qmake!
qmake-qt5 'qscintilla.pro'
make
# plugin for Qt5 Designer
cd '../designer-Qt4Qt5'
qmake-qt5 'designer.pro' INCLUDEPATH+='../Qt4Qt5' QMAKE_LIBDIR+='../Qt4Qt5'
make
# Python bindings
cd '../Python'
python3 'configure.py' --pyqt='PyQt5' --qmake='/usr/bin/qmake-qt5' \
--qsci-incdir='../Qt4Qt5' --qsci-libdir='../Qt4Qt5'
make
If successful, you can then install everything (as root):
cd 'path/to/src/Qt4Qt5'
make install
cd '../designer-Qt4Qt5'
make install
cd '../Python'
make install
ekhumoro's solution above did not quite work for me - let's just say maybe I missed something, or it's an environment-specific thing.
Anyway.... I did what ekhumoro advised except didn't edit these three files: (XXX)
- designer-Qt4Qt5/designer.pro
- Qt4Qt5/features/qscintilla2.prf
- Qt4Qt5/qscintilla.pro
the reason for editing them seems sound, but at the end of the day Eric install failed with:
Sorry, please install QScintilla2 and its PyQt5/PyQt4 wrapper.
Error:
dlopen(/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/PyQt5/Qsci.so, 2):
Library not loaded: libqscintilla2_qt5.12.dylib
^^^^
Referenced from: /Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/PyQt5/Qsci.so
Reason: image not found
note the _qt5 marked with ^^^^ - theoretically that should resolve, but for me it did not. I tried all kinds of things to no avail. May be my ignorance of some setting.
I expected ekhumoro's instructions to work, since the edits suggested for the 3 files - see (XXX) - configure Make to create libraries with _qt5.
I tried many things - symlinks, etcetc., but at the end of the day, leaving out (XXX) allowed everything to proceed properly.
So - in summary, *if you don't need to have QScintilla work simultaneously with PyQt4 and PyQt5*, do ekhumoro's advice minus the stuff at (XXX) - that way, Eric should install without problems.
Take care with the information above: it will probably clobber QScintilla libs for Qt4
I guess the most important is --pyqt=PyQt5 which leads to using sip/qscimod5.sip instead of sip/qscimod4.sip. Difference is that it contains line %Import QtWidgets/QtWidgetsmod.sip which is essential for QAbstractScrollArea.
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.
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
How to compile bash? I did small modifications to the code I got from http://ftp.gnu.org/gnu/bash/bash-4.2.tar.gz. I want to see those changes. Can anyone please point to me simple steps to compile bash?
You can first run
cd bash-4.2
./configure --prefix=/usr \
--bindir=/bin \
--htmldir=/usr/share/doc/bash-4.2 \
--without-bash-malloc \
--with-installed-readline
make
make install
Also refer http://www.linuxfromscratch.org/lfs/view/development/chapter06/bash.html for more information
The simplest way to compile Bash is:
cd to the directory containing the source code and type ./configure to configure Bash for your system. If you're using csh on an old version of System V, you might need to type sh ./configure instead to prevent csh from trying to execute configure itself.
Running configure takes some time. While running, it prints messages telling which features it is checking for.
like
/bash-4.2$ ./configure
Type make to compile Bash and build the bashbug bug reporting script.
/bash-4.2$ make
Optionally, type make tests to run the Bash test suite.
/bash-4.2$ make tests
Type make install to install bash and bashbug. This will also install the manual pages and Info file.
/bash-4.2$ make install
The configure shell script attempts to guess correct values for various system-dependent variables used during compilation.
I am trying to install Code::Blocks 10.05 from (non-SVN) sources (codeblocks-10.05-src.tar.bz2). My OS is Ubuntu 11.04. I needed to download and install wxWidgets first (I now have wxGTK-2.8.12), which seemed to work. I compiled it according to these instructions:
http://wiki.codeblocks.org/index.php?title=Installing_Code::Blocks_from_source_on_Linux
Then I configured C::B with
./configure --with-wx-config=/opt/wx/2.8/bin/wx-config
and ran
export LDFLAGS="-Wl,-R /opt/wx/2.8/lib"
make
sudo -i
make install
When trying to run C::B, I get the following error:
codeblocks: error while loading shared libraries: libwx_gtk2u-2.8.so.0: cannot open shared object file: No such file or directory
The same question was asked here: error while loading shared libraries, but the suggested solution (namely adding the wxWidgets config to the options passed to configure) didn't work for me.
The output of wx-config --prefix is /opt/wx/2.8,
The output of wx-config --libs is -L/opt/wx/2.8/lib -pthread -lwx_gtk2u-2.8,
and that of which wx-config is /opt/wx/2.8/bin/wx-config.
I looked for the library and found /opt/wx/lib/libwx_gtk2u-2.8.so.0 to be a link to libwx_gtk2u-2.8.so.0.8.0 in the same folder.
What might be wrong here?
The problem is that the program cannot find the WX widgets libraries at run time. You will need to set your LD_LIBRARY_PATH variable to include the location of wxWidgets like this:
LD_LIBRARY_PATH=/opt/wx/2.8/lib ./codeblocks
The reason why its failing is because you compiled codeblocks against wxWidgets found in /opt/ and not the one installed in /usr/; the program doesn't know to look in /opt for the wx libraries.
Probably the easiest way to get code::blocks up and running on Ubuntu is to just install it via the Synaptic Package Manager. Just type in codeblocks into 'Quick search'. Find codeblocks on the list and just right-click to mark for install. Any dependencies and missing libraries needed will automatically be handled and installed by Synaptic as necessary.
If you're interested in trying the C::B nightly builds on Ubuntu then you'll want to checkout Jens' unofficial debian-repository here.
You can visit Why do I have to define LD_LIBRARY_PATH with an export every time I run my application? for a more generic case. For a particular case like yours you can follow the below given steps
If you had installed wxGTK then you would see the file in /usr/local/lib. You would get this error when the the above path is not as part of the makefile. I received this error while starting wxFormBuilder after building from source on CentOS. There are 2 approaches.
Approach 1: Putting the path in .bashrc
gedit /home/{your-username}/.bashrc
Then after the line # User specific aliases and functions paste the following
export $LD_LIBRARY_PATH=/usr/local/lib.
This would work for fine but for the current login, but for other users like root you might have to do the same in the respective .bashrc files.
Approach 2: Creating your own conf files
cd /etc/ld.so.conf.d
gedit wxformbuilder.conf
Give the path /usr/local/lib and save the file.
ldconfig (To update the library path).