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.
Related
I have a script that must be run in Perl 5.10.1, although my university's linux cluster system uses the most recent version of Perl. I tried to install Perlbrew, but I don't think it worked.
I'm not sure how to specify the perl version in the shebang because of how I call/run this script. There is "cluster.pl", which is run by running "./command.txt".
Also, I don't think I can install Perlbrew because it's the university's linux system: After copy-pasting the installation commands, my terminal screen said the perlbrew patch was installed, but when I used "perlbrew install perl-5.10.1", it would say "command perlbrew not found" I don't know how to run the script
As of now, cluster.pl has this shebang:
#!/usr/bin/perl
One related question said to write this in the command line
/program/perl_v5.6.1/bin/perl scriptName.pl
#OP needed to use version 5.6.1, unlike me (I need 5.10.1)
However, I don't know whether "program" is OP's directory or a mandatory part of the path
Below is command.txt, which has the necessary input arguments:
#this is command.txt
./cluster.pl Datachr1 2 galGal5.Chroinfo.txt
Essentially, where would the suggested shebang go? Would I include "program" in my path too?
If you wrap your script in Perl's packaging framework, this is handled for you automatically. When it installs scripts, it changes the shebang line with the actual perl. You end up with something like this at the top of the file:
#!/usr/local/perls/perl-5.30.0/bin/perl
eval 'exec /usr/local/perls/perl-5.30.0/bin/perl -S $0 ${1+"$#"}'
if $running_under_some_shell;
#!/usr/local/bin/perl
You might try this with my app-rhich distribution. Download the tarball and run the Makefile.PL with the perl you want. Run make and it builds stuff into the blib staging directory. You should see the modified shebang there:
$ /Users/brian/bin/perls/perl5.30.0 MAkefile.PL
Checking if your kit is complete...
Looks good
WARNING: Older versions of ExtUtils::MakeMaker may errantly install README.pod as part of this distribution. It is recommended to avoid using this path in CPAN modules.
Generating a Unix-style Makefile
Writing Makefile for App::rhich
Writing MYMETA.yml and MYMETA.json
$ make build
make: *** No rule to make target `build'. Stop.
$ make
cp lib/App/rhich.pm blib/lib/App/rhich.pm
cp script/rhich blib/script/rhich
"/usr/local/perls/perl-5.30.0/bin/perl" -MExtUtils::MY -e 'MY->fixin(shift)' -- blib/script/rhich
Manifying 1 pod document
Manifying 1 pod document
brian#otter app-rhich (master)[3125]
$ more blib/script/
#!/usr/local/perls/perl-5.30.0/bin/perl
package rhich;
use strict;
use warnings;
However, if your path to perl is a symlink to some other perl, this can get confused. I don't use perlbrew because I don't think it adds much other than saving you looking up a download URL. I install multiple perls (and How should I install more than one version of Perl?) and can use paths to them so I know which version using. There's a similar problem with env depending on how you set up your path. How you handle that is based on how you decide to manage things, but it's these sorts of questions that show that the tools of convenience aren't really that convenient.
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 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 want to install vimgdb,in the directory ~/vim/vim73/src. Execute ./configure and make.
The error message was:make:***no rule to create object"#GDB_OBJ#".
I tried to use:make "CFLAGS="-O2 -D_FORTIFY_SOURCE=1",the result was the same as before.So what should I do to compile it successfully?
The installation instructions I found say:
IMPORTANT NOTE: you must run make (not ./configure), and if you run ./configure then you must add the --enable-gdb command line argument in order to include the gdb feature (vimgdb) in vim.
I'm at a bit of a loss, the problem is that I need to install GCC on X-Linux. Basically what's happening is I have been told to try and get wine on X-Linux...so I transfer the files over run the configure and I'm told I need GCC, so I download GCC only to find that I don't have a 'make' command...So I download the tar for the make command, turns out make needs a C compiler to run!
I'm stuck in a kind of chicken-and-the-egg loop here....help me!
A GNU Make source tarball contains a build.sh script to resolve this chicken-and-egg situation. From the README:
If you need to build GNU Make and have no other make program to use,
you can use the shell script build.sh instead. To do this, first run
configure as described in INSTALL. Then, instead of typing make to
build the program, type sh build.sh. This should compile the program
in the current directory. Then you will have a Make program that you
can use for ./make install, or whatever else.