and in the EMBOSS distribution, installed under share/EMBOSS/doc/programs/html (HTML files) and share/EMBOSS/doc/programs/text (plan text, as used by the tfm program).
You can also use thtfm program to display the plain text documentation, adding the name of the program on the command line, for example:
% tfm seqret
ftp://ftp.no.embnet.org/embnet/tutorials/EMBOSS_QG.ps (Postscript file)
ftp://ftp.no.embnet.org/embnet/tutorials/EMBOSS_QG.doc (Word 97 format)
rm config.cache (if that file exists) make clean ./configure make
If this is the first time trying to compile all you need to do is:-
./configure make
The above will produce the EMBOSS programs in the 'emboss' subdirectory and you can set your PATH variable to point there. This method is suitable for EMBOSS developers.
For system-wide installations we recommend installing the EMBOSS programs into a different directory to the source code (e.g. in the directory tree /usr/local/emboss). To do this type [e.g.]:
./configure --prefix=/usr/local/emboss
make [to make sure there are no errors, then]
make install [if there are no errors]
You should then add [e.g.] /usr/local/emboss/bin to your PATH variable [e.g.]
set path=(/usr/local/emboss/bin $path) [csh/tcsh shells]
export PATH="$PATH /usr/local/emboss/bin" [sh/bash shells]
setenv CC "cc -D__amd64__" [csh/tcsh shells] or export CC="cc -D__amd64__" [bash/sh]
Note that the above is case sensitive, there is only one space character between the quotes and that there are 4 underscores in total (two each side of the amd64).
xorg-x11-devel (xorg-based X11 distros) or
XFree86-devel (XFree86-based X11 distros)
You can unpack the tar.gz files in any directory, and install them in a common area.
By default everything (including EMBOSS) installs in /usr/local but in the examples below we use /home/joe/local
Note: gd does not use a ./configure script, and will fail at the "make install" stage if the installation directory does not have a /bin subdirectory. You can create this directory (e.g. /home/joe/local/bin) if it does not already exist.
To install, pick up the sources (jpeg is optional) and then:
gunzip -c zlib-1.1.4.tar.gz | tar xf - gunzip -c libpng-1.2.5.tar.gz | tar xf - gunzip -c jpegsrc.v6b.tar.gz | tar xf - gunzip -c gd-2.0.28.tar.gz | tar xf - ln -s zlib-1.1.4 zlib ln -s jpeg-6b jpeg ln -s libpng-1.2.5 libpng ln -s gd-2.0.28 gd
If these directories do not exist, "make install" for jpeg will need them:
mkdir /home/joe/local/bin mkdir /home/joe/local/man mkdir /home/joe/local/man/man1 cd zlib ./configure --prefix=/home/joe/local make make install cd .. cd jpeg ./configure --prefix=/home/joe/local make make test make install cd .. cd libpng ./configure --prefix=/home/joe/local
But this says:
There is no "configure" script for Libpng-1.2.5. Instead, please copy the appropriate makefile for your system from the "scripts" directory. Read the INSTALL file for more details.
so copy the file, for example "cp scripts/makefile.linux makefile"
##
## edit makefile, change prefix to be /home/joe/local
## and any other places - some files point to ../zlib
## others use /usr/local/lib and /usr/local/include
##
## on HP-UX this is trickier. CFLAGS has to match zlib
##
make
make install
cd ..
cd gd
##
## for 1.x versions, edit Makefile, change:
## INCLUDEDIRS, LIBDIRS, INSTALL_LIB, INSTALL_INCLUDE, INSTALL_BIN
## all /usr/local
## to /home/joe/local
##
## for 2.x versions, we use ./configure (hurrah!)
./configure --prefix=/home/joe/local --with-png=/home/joe/local \
--with-jpeg=/home/joe/local
make
make install
cd ..
If the gd or jpeg "make install" fails with a warning about the "bin" "man" or "man/man1" directory, you need to create it by hand (see above).
To compile with the local version your EMBOSS ./configure line should now read:-
./configure --with-pngdriver=/home/joe/local
This will look for the graphics libraries in your local installation under /home/joe/local instead of a system-wide location
configure keeps a copy of the previous settings. You may need to delete file config.cache and config.status if configure has been run before.
The main problem is that I have an old version of libz but no lib gd in my system libraries and EMBOSS looks there first to try to locate these libraries. I have the correct versions installed elsewhere.
Deleting -lgd -lz -lpng from CFLAGS in the ajax directory Makefile works but is an ugly solution and not really ideal.
Are there any suggestions for setting the library search path or am I missing something really obvious? A) There are the
--without-pngdriver
and
--with-pngdriver=dir
flags. Did you try them? If the libraries are in /opt/png/lib then set "dir" to /opt/png i.e. one level above the "lib" directory.
Make sure you have cvs on your system Then log into the cvs server at 'open-bio.org' as: user 'cvs' with password 'cvs'.
Make sure you have cvs on your system Then log into the cvs server at
cvs -d :pserver:cvs@cvs.open-bio.org:/home/repository/emboss login
Make sure you have cvs on your system. Then log into the cvs server at The password is 'cvs'
To checkout the EMBOSS source code tree, put yourself in a local directory just above where you want to see the EMBOSS directory created. For example if you wanted EMBOSS to be seen as /home/joe/src/emboss... then cd into /home/joe/src then checkout the repository by typing:
cvs -d :pserver:cvs@cvs.open-bio.org:/home/repository/emboss checkout emboss
Or if you want to update a previously checked-out source code tree:
cvs -d :pserver:cvs@cvs.open-bio.org:/home/repository/emboss checkout emboss cvs -d :pserver:cvs@cvs.open-bio.org:/home/repository/emboss update
You can logout from the CVS server with:
cvs -d :pserver:cvs@cvs.open-bio.org:/home/repository/emboss logout
(this is a read only server).
The gcc compiler is recommended. The host cc compiler should work, but there is a problem with automake which generates the Makefiles. automake generates dependencies for you, in a '.deps' subdirectory, to keep Makefile.in clean, but since automake 1.4 this uses gcc. If you are not using gcc, you can use 'automake --include-deps' to put the dependencies into each Makefile.in file
Scripts are available to compile the cvs version.
i.e. source make-static-developers will compile a statically linked EMBOSS.
What this actually does is:-
aclocal -I m4 autoconf automake -a # --include-deps # if you are not using gcc ./configure --disable-shared make
For more info on the configurability of the build try
./configure --help
1) Go to the mse directory
cd embassy/mse
2) make the configuration file
aclocal
autoconf
automake
3) configure and compile
./configure (use same options as you used to compile emboss)
make
make install
b) from MSE-1.0.0.tar.gz
available from our FTP server ftp://emboss.open-bio.org/pub/EMBOSS/ in file MSE-1.0.0.tar.gz
If you have done a full installation of EMBOSS using a 'prefix' e.g. you configured with ./configure --prefix=/usr/local/emboss and followed this with a 'make install' then:
1) gunzip and untar the file anywhere
gunzip MSE-1.0.0.tar.gz
tar xvf MSE-1.0.0.tar
2) go into the mse directory
cd MSE-1.0.0
3) configure using the same prefix and compile [e.g.]:
./configure --prefix=/usr/local/emboss
make
make install
N.B. If you configured without using a prefix but did do a 'make install' (or specified a prefix of /usr/local, which amounts to the same thing) then you must configure using:
./configure --prefix=/usr/local --enable-localforce
If, on the other hand, you did not do a 'make install' then:
1) Go to the emboss directory
cd EMBOSS-2.10.0
2) make new directory embassy if it does not exist already.
mkdir embassy
3) Go into that directory
cd embassy
4) gunzip and untar the file
gunzip MSE-1.0.0.tar.gz
tar xvf MSE-1.0.0.tar
5) go into the mse directory
cd MSE-1.0.0
6) configure and compile
./configure (use same options as you used to compile emboss)
make
1) Go to the phylip directory
cd embassy/phylip
2) make the configuration file
aclocal
autoconf
automake
3) configure and compile
./configure (use same options as you used to compile emboss)
make
make install
b) from PHYLIP-3.6b.tar.gz
available from our FTP server ftp://emboss.open-bio.org/pub/EMBOSS/ in file PHYLIP-3.6b.tar.gz
If you have done a full installation of EMBOSS using a 'prefix' e.g. you configured with ./configure --prefix=/usr/local/emboss and followed this with a 'make install' (highly recommended) then:
1) gunzip and untar the file anywhere
gunzip PHYLIP-3.6b.tar.gz
tar xf PHYLIP-3.6b.tar
2) go into the phylip directory
cd PHYLIP-3.6b
3) configure and compile
./configure (use same options as you used to compile emboss)
make
make install
N.B. If you configured without using a prefix but did do
a 'make install' (or specified a prefix of /usr/local,
which amounts to the same thing) then you must configure
using:
./configure --prefix=/usr/local --enable-localforce
If, on the other hand, you did not do a 'make install' of EMBOSS then:
1) Go to the emboss directory
cd EMBOSS-3.0.0
2) make new directory embassy if it does not exist already.
mkdir embassy
3) Go into that directory
cd embassy
4) gunzip and untar the file
gunzip PHYLIP-3.6b.tar.gz
tar xvf PHYLIP-3.6b.tar
5) go into the phylip directory
cd PHYLIP-3.6b
6) configure and compile
./configure (use same options as you used to compile emboss)
make
7) Set your PATH to include the full path of the 'src'
directory
If you have installed PHYLIP to the same top directory as EMBOSS i.e. by default this is usually /usr/local/ (via make install) then if you set the following in your .embossrc file then your PHYLIP acd files will be found in
/usr/local/share/EMBOSS/acd/
if you have not installed PHYLIP then you will can set emboss_acdroot to the directory containing the acd files or copy them to the emboss/acd directory.
To tell EMBOSS where to find the files, specify the full path of the ACD directory in your ~/.embossrc file, or in the emboss.default file.
env emboss_acdroot /usr/local/share/EMBOSS/acd/
b) the associated software will use the emboss acd files so the naming of output/input files is taken care of and will check all values before the program is run. Command line arguments are used instead interactive menu based ones.
My intention was to simply transfer the Emboss install directory and the Data directory to all sites, using symlinks where necessary so that the directory paths corresponded.
However, when testing this I have found a couple of problems;
1) Although the Emboss programs work, I can't see any of the extracted data.
For instance remap gives the error;
EMBOSS An error in remap.c at line 167:
Cannot locate enzyme file. Run REBASEEXTRACT
This is despite the fact that I have both the Emboss install and the Data directories in the same place as on the development machine (which works).
2) The other major problem is that I can no longer see my databases defined in emboss.default. Again, the file exists, and is in the same place as on the development machine, but the box it is transferred to gives an empty list from showdb.
Does anyone know where Emboss stores the information about the location of these files? It can't have installed anything outside the original installation directory (wasn't installed as root), so I'm guessing that the problem stems from the program resolving symlinks at some point.
A) It is inside the binaries ...
EMBOSS 'knows' the location of the files because it is picked up during the configure, when you build your copy, and included in the binaries.
You can see it during compilation, especially of ajnam.c (where it is used):
-DAJAX_FIXED_ROOT=\"/full/source/path\" -DPREFIX=\"/install/prefix/path\"
To copy binaries, you need to define environment variable(s) to override the compile-time definitions, unless you can make the path (e.g. /usr/local) the same for the installations at each site.
emboss.default can set environment variables too, but you need to tell EMBOSS where to find that file.
setenv EMBOSS_ROOT /dir/for/default/file
and then, in the emboss.default file you can set:
SET EMBOSS_ACDROOT /install/dir/share/EMBOSS/acd
or (this overrides it) you can use another environment variable:
SET EMBOSS_ACDROOT /install/dir/share/EMBOSS/acd
(Peter Rice 22 Nov 2000)
If you do not have SRS, you can build your own index files using dbiflat, dbigcg (if you have GCG), dbiblast (if you have blast) and dbifasta. This is the usual solution for sites that have no other database indexing in use.
You can also use SRS servers remotely, to get single entries, using their URLs. No extra software is needed (EMBOSS just uses the HTTP protocol).
Of course, if you really need to build your own SRS indices you could install it. SRS is a commercial product, but academic licences are available. But as I now work for the developers of SRS, and this is the EMBOSS bug mailing list, I shall say no more :-)
(Peter Rice 9 Jan 2001)
make "LDFLAGS=-Wl,-static"
(Alan Bleasby 14 Feb 2001)
Here are some of those:-
ps -> Postscript cps -> Colour Postscript x11 -> X display. (also called xterm and xwindows) hpgl -> HP Laserjet III, HPGL emulation mode. png -> PNG (you will need png, z and gd libraries for this) tek -> Tektronix Terminal none -> None. data -> Writes out points to a file for graphs. meta -> plplot meta file.
If for some reason you do not have the required libraries and your system support group will not update these ( In particular gd, as the older versions support GIF which is NOT supported for many years) then install all three latest versions (z,gd,png) to a new directory and then add this new directory to your configure line for EMBOSS. Look to see whether your operating system provides GD support via an update before installing from source code.
i.e.
make clean rm config.cache ./configure --with-pngdriver=/home/joe/new
as I installed gd etc using --prefix=/home/joe/new in the configure of each.
If you have recently installed the libraries to your system then
make clean make clean rm config.cache ./configure
By removing config.cache you are telling the system to check again for what is available as these are stored in that file.
make clean removes all the current objects and EMBOSS libraries as these will now need to include the png driver code.
GD) http://www.libgd.org/ Z) http://www.mirror.ac.uk/sites/ftp.cdrom.com/pub/infozip/zlib/ JPEG) http://www.ijg.org/ PNG) http://www.mirror.ac.uk/sites/ftp.libpng.org/pub/png/libpng.html
These also list the various mirror sites for non UK people.
Alternatively, using ftp :-
GD) (boutell.com no longer allows FTP, no known mirror sites, use HTTP) Z) ftp://ftp.info-zip.org/pub/infozip/zlib/zlib-1.1.3.tar.gz JPEG) ftp://ftp.uu.net/graphics/jpeg/ PNG) ftp://swrinde.nde.swri.edu/pub/png/src/libpng.1.2.1.tar.gz
SP1 black
SP2 white
SP3 red
SP4 green
SP5 blue
SP6 cyan
SP7 magenta
SP8 yellow
Otherwise your output will have different colours.
Robert Maier promised a while back to LGPL them but has not yet. Pity. Makes all the difference for linking in third party applications to EMBOSS.
A) You should be able to compile them from the source on just about any Unix platform.
http://www.info-zip.org/pub/infozip/zlib/ http://libpng.sourceforge.net/ http://www.boutell.com/gd/
You should change the configuration settings so that it uses 'PseudoColor'. In version 6.1 of Hummingbird Exceed, this is done by clicking on the Exceed section of the Windows 98 tool bar at the bottom of the screen. Select 'Tools', then 'Configuration', then Screen Definition. A window will appear.
In the 'Server Visual' popup menu on the left, select 'PseudoColor'. Click on 'OK'.
'transeq' has been written to only read in one of the standard translation files:
EGC.0 EGC.1 EGC.2 EGC.3 EGC.4 EGC.5 EGC.6 EGC.9 EGC.10 EGC.12 EGC.11 EGC.13 EGC.14 EGC.15
These files are the only ones that you can specify to 'transeq'.
If you wish to create your own specialised translation table, then you should pick one of them to amend.
For instance you may decide that you will use the file EGC.15 as you would never want to use this otherwise.
Use the program 'embossdata' to get a copy of this file:
% embossdata -fetch -filename EGC.15 Finds or fetches the data files read in by the EMBOSS programs File '/packages/emboss/emboss/data/EGC.15' has been copied successfully.
Edit the file EGC.15 to suit your requirements.
Specify '-table 15' when you run 'transeq' to use this altered file. 'transeq' will then look for the file 'EGC.15' and will find it in your current directory before it finds the default one in the EMBOSS_DATA directory. It will therefore use your local copy.
You may get confused with many copies of changed files floating about. To check which copy of a file is being used - the default EMBOSS_DATA one or a potential local copy, use 'embossdata':
% embossdata -filename EGC.15 Finds or fetches the data files read in by the EMBOSS programs # The following directories can contain EMBOSS data files. # They are searched in the following order until the file is found. # If the directory does not exist, then this is noted below. # '.' is the UNIX name for your current working directory. File ./EGC.15 Exists File .embossdata/EGC.15 Does not exist File /people/gwilliam/EGC.15 Does not exist File /people/gwilliam/.embossdata/EGC.15 Does not exist File /packages/emboss/emboss/data/EGC.15 Exists
This shows that a copy of EGC.15 exists in your current directory and so will be used in preference to the default one in the EMBOSS_DATA directory.
You should consider using the '-ossingle' qualifier. This writes sequences to separate FASTA files, but the file names depend on the sequence ID. This is rarely used. It is there because -ossingle is the default for GCG output format. The output filename is currently ignored when ossingle is used, and the filename depends on each individual sequence.
gcg, embl, swissprot, fasta, ncbi, genbank, nbrf, codata, strider, clustal, phylip, acedb, msf, ig, staden, text, raw, asis
For example:
% program -seq asis::ATGGTGAGGAGAGTTGTGATGAGA
> cat seq1 A > cat seq2 I % water seq1 seq2 -stdout -auto Smith-Waterman local alignment. An error has been found: Sequence is not nucleic
Here, 'water' automatically (and wrongly) thinks that A is adenosine instead of alanine and fails when it reads in seq2 and expects to find another nucleic acid sequence - but 'I' is not a valid base and so it fails.
A) For many sequence formats there is no way to specify the sequence type in the file, so EMBOSS has to guess.
There is a flag that can force EMBOSS programs to treat sequences as nucleic or protein.
'water -help -verbose'
shows the full list of sequence qualifiers.
If you follow the sequence USA with '-sprotein' EMBOSS will check that it is a valid protein sequence.
If you need to force a sequence to be DNA, the qualifier is '-snucleotide'
The qualifier must follow the sequence to apply to one sequence, or can go at the start of the command line to refer to all sequences, for example:
'water -sprotein seq4 seq3 -stdout -auto'
You can also use '-sprotein1' anywhere on the command line to refer to the first sequence and '-sprotein2' to refer to the second sequence.
Of course, like all EMBOSS qualifiers, you can shorten them so long as they are still unique. In this case, '-sp' and '-sn' will work (or '-sp1' and '-sp2' if you need the numbers).
Of course, some programs (and some program options) can take up too much memory, or simply run very slowly.
You might have a constraint imposed on your usage of memory.
Try using the Unix command 'limit' to look at such constraints.
Try using the Unix command 'unlimit' to remove the constraints, eg:
% unlimit stacksize
% unlimit vmemoryuse
$ENV{HOME}= i.e. /usr/local/apache
$ENV{EMBOSS_DATA}=
These two are important, but you can also pass other "constants".
Instead of 3.6 residues per turn, (5 turns in 18 steps) you seem to have a helix with 8 turns in 18 steps (4 in 9).
Try -turns=4 -steps=9 ... but only if you are sure that is the way your helix goes.
I suppose we could play with checking for common factors in pepwheel, but I don't know of any biologically meaningful setting that would cause problems.
prettyplot -auto ~/wordtest/globin-nogap.msf -graph ps Created prettyplot.ps
The name is generated automatically. To set this to something more discriptive use -go .i.e
prettyplot -auto ~/wordtest/globin-nogap.msf -graph ps -go=hello Created hello.ps
Then use the SAVE command which will prompt for the file name.
Note: Rodger Staden's group lost their funding on 1st April 2003. The Staden package is now available from http://staden.sourceforge.net/