From David.Bauer at SCHERING.DE Wed Nov 1 02:21:07 2006 From: David.Bauer at SCHERING.DE (David.Bauer at SCHERING.DE) Date: Wed, 1 Nov 2006 08:21:07 +0100 Subject: [EMBOSS] Batch retrieval of taxonomy/species names using entret..... In-Reply-To: <45479B8C.5080800@ebi.ac.uk> Message-ID: If you want to parse Swissprot files which you get from entret, you could have a look at Swissknife, which is "An object-oriented Perl library to handle Swiss-Prot entries": http://swissknife.sourceforge.net/docs/ This can be used to access all header information in sprot files, also the information in the special format CC lines. David. emboss-bounces at lists.open-bio.org schrieb am 31/10/2006 19:53:00: > Hi Richard, > > Richard Rothery wrote: > > I am interested in using entret to retrieve single field entries from > > swissprot or sptrembl. Specifically, I would like to feed entret a list > > of accessions and have it return a file with the species names and/or > > taxonomies. I intend to use this information to compare with my > > phylogeny analyses of clustalw alignments. > > EMBOSS stores the full text in entret without parsing. > > We could try to extract specific fields but it is not easy to definethem for > all formats. > > You can do this with SRS. Try the EBI server for example: > > Go to the library page > > Select UniProtKB/SwissProt (or UniProtKB/TrEMBL) > > Select "standard query form" > > Enter your query in the top part (e.g. accession number) > > In the "create a view" section click the "list" button to egt the original > lines. Select anything taxonomic from the pull down list (control-click to > select more than one) > > Press "search". > > refine your query. You will see the URL at the top that can be used > to retrieve > data when you are happy. > > Failing that, you could just parse out the ID and O* lines from > entret using a > simple perl script. > > Hope that helps, > > Peter > > _______________________________________________ > EMBOSS mailing list > EMBOSS at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/emboss From msarachu at biol.unlp.edu.ar Wed Nov 1 17:30:03 2006 From: msarachu at biol.unlp.edu.ar (=?ISO-8859-1?Q?Mart=EDn_Sarachu?=) Date: Wed, 01 Nov 2006 19:30:03 -0300 Subject: [EMBOSS] wEMBOSS-1.7.0 released Message-ID: <45491FEB.2070902@biol.unlp.edu.ar> This release is compatible both with EMBOSS-4 and 3. A few bugs fixed and some new features in this version. wrappers4EMBOSS-1.5 is distributed with this release as an optional to install. wEMBOSS can be downloaded from http://www.wemboss.org Best regards, The wEMBOSS team From molatwork at yahoo.es Thu Nov 2 03:00:20 2006 From: molatwork at yahoo.es (Miguel Ortiz Lombardia) Date: Thu, 02 Nov 2006 09:00:20 +0100 Subject: [EMBOSS] [Fwd: [Staden] Re: using emboss programs from spin] Message-ID: <4549A594.4050205@yahoo.es> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear all, A few weeks ago I sent a message to the Staden mailing list asking for support on its interface to EMBOSS. I was given advice on how to get it kind of working (thanks to Guy Bottu!) but I was also told that due to the cut of the support for the Staden team, the improved version of spin (spin2) was not fully developed. Therefore, the Staden interface for EMBOSS is incomplete. Here, a number of users are quite afraid of the command line ;-{ so they would appreciate a graphic interface to EMBOSS. We tried Jemboss first, but got a number of problems that we couldn't solve (essentially with some results text files being corrupted). Then, I met with this interface from the Staden package, and found it very useful, to a certain extent. Hence, advised by Guy and Peter Rice, I hereby show our interest :) in such an interface, which would combine the goodies of two excellent packages. Thank you very much for your good work. Cheers, Miguel - -- Miguel Ortiz Lombard?a Centro de Investigaciones Oncol?gicas C/ Melchor Fern?ndez Almagro, 3 28029 Madrid, Spain Tel. +34 912 246 900 Fax. +34 912 246 976 email: molatwork at yahoo.es www: http://www.ysbl.york.ac.uk/~mol/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Le travail est ce que l'homme a trouv? de mieux pour ne rien faire de sa vie. (Raoul Vaneigem) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFFSaWTF6oOrDvhbQIRAqL+AKClBRlA1gI41N3vMUB7QcvAd7kzoQCfVJ5b K2c6TvGITSmm3mkBl8nf8jY= =4zxW -----END PGP SIGNATURE----- -------------- next part -------------- An embedded message was scrubbed... From: Peter Rice Subject: [Staden] Re: using emboss programs from spin Date: Wed, 01 Nov 2006 12:03:42 +0000 Size: 4043 Url: http://lists.open-bio.org/pipermail/emboss/attachments/20061102/e8fa3a0e/attachment.mht From bernd.web at gmail.com Thu Nov 2 11:16:28 2006 From: bernd.web at gmail.com (Bernd Web) Date: Thu, 2 Nov 2006 17:16:28 +0100 Subject: [EMBOSS] IDs in output Message-ID: <716af09c0611020816r3d5c30dg1b1c6f1f4d5fea5d@mail.gmail.com> Hi, Sometimes I use an EMBOSS command directly on a FastA file. I wonder if it is possible to select the ID used in the output, esp for FastA records with an NCBI defline. >gi|248166|g|AA21972.1| description... in the output of an EMBOSS command becomes: AA21972.1| It would be very easy if the ID could be chosen to be the GI number. Now the ID used depends on the GI record (sp, pdb, pir) show different IDs in EMBOSS output. Is this possible to choose the fixed GI number as record ID? Regards, Bernd From smiddha at indiana.edu Thu Nov 2 10:49:42 2006 From: smiddha at indiana.edu (Sumit Middha) Date: Thu, 02 Nov 2006 10:49:42 -0500 Subject: [EMBOSS] Emboss-explorer error Message-ID: <454A1396.3020501@indiana.edu> Hi, I have setup emboss-explorer and it works fine for most of the tools. However, fuzznuc, fuzztran seem to give an error (unknown datatype pattern). Server logs: [Wed Nov 01 12:51:52 2006] [error] [client 156.56.96.41] unknown datatype pattern in fuzznuc at /bioportal/web/tools/emboss-explorer/lib/EMBOSS/GUI.pm line 246, referer: http://bioportal.cgb.indiana.edu/cgi-bin/emboss/menu linked from - http://bioportal.cgb.indiana.edu/cgi-bin/emboss/fuzznuc fuzznuc works fine from command line. Thanks, Sumit From smiddha at indiana.edu Thu Nov 2 10:49:26 2006 From: smiddha at indiana.edu (Sumit Middha) Date: Thu, 02 Nov 2006 10:49:26 -0500 Subject: [EMBOSS] Error: Invalid graph value 'png' In-Reply-To: References: Message-ID: <454A1386.2000001@indiana.edu> > Hi, > > I used the command to make sure it finds and installs with png option > ./configure --prefix=/bioportal/sw/encap/emboss-4.0.0 > --with-pngdriver=/local > > However, it still does not include png in the Graph type. Its a > solaris machine I work on > > > uname -a > SunOS helix 5.10 Generic_118833-22 sun4u sparc SUNW,Sun-Fire-480R > > > ls /local/lib/*png* > /local/lib/libpng.a /local/lib/libpng12.a > /local/lib/libpng.so /local/lib/libpng12.so > /local/lib/libpng.so.3 /local/lib/libpng12.so.0 > /local/lib/libpng.so.3.1.2.7 /local/lib/libpng12.so.0.1.2.7 > > > ls /local/include/*png* > /local/include/png.h /local/include/pngconf.h > > /local/include/libpng: > png.h pngconf.h > > /local/include/libpng12: > png.h pngconf.h > > Can someone please suggest a way out ? > > Thanks, > Sumit > ------------------------------------------------------------------------ > > This file contains any messages produced by compilers while > running configure, to aid debugging if configure makes a mistake. > > It was created by configure, which was > generated by GNU Autoconf 2.59. Invocation command line was > > $ ./configure --prefix=/bioportal/sw/encap/emboss-4.0.0 --with-pngdriver=/local > > ## --------- ## > ## Platform. ## > ## --------- ## > > hostname = helix > uname -m = sun4u > uname -r = 5.10 > uname -s = SunOS > uname -v = Generic_118833-22 > > /usr/bin/uname -p = sparc > /bin/uname -X = System = SunOS > Node = helix > Release = 5.10 > KernelID = Generic_118833-22 > Machine = sun4u > BusType = > Serial = > Users = > OEM# = 0 > Origin# = 1 > NumCPU = 4 > > /bin/arch = sun4 > /usr/bin/arch -k = sun4u > /usr/convex/getsysinfo = unknown > hostinfo = unknown > /bin/machine = unknown > /usr/bin/oslevel = unknown > /bin/universe = unknown > > PATH: /local/bin > PATH: /bin > PATH: /usr/bin > PATH: /usr/ccs/bin > PATH: /opt/SUNWspro/bin > PATH: local/sbin > PATH: /usr/sbin > PATH: /sbin > PATH: /local/bin > PATH: /usr/bin > PATH: /usr/ccs/bin > PATH: /usr/openwin/bin > > > ## ----------- ## > ## Core tests. ## > ## ----------- ## > > configure:1557: checking for a BSD-compatible install > configure:1612: result: /local/bin/install -c > configure:1623: checking whether build environment is sane > configure:1666: result: yes > configure:1731: checking for gawk > configure:1747: found /local/bin/gawk > configure:1757: result: gawk > configure:1767: checking whether make sets $(MAKE) > configure:1787: result: yes > configure:1961: checking for gawk > configure:1987: result: gawk > configure:2044: checking for gcc > configure:2060: found /local/bin/gcc > configure:2070: result: gcc > configure:2314: checking for C compiler version > configure:2317: gcc --version &5 > gcc (GCC) 3.4.4 > Copyright (C) 2004 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > configure:2320: $? = 0 > configure:2322: gcc -v &5 > Reading specs from /local/encap/gcc-3.4.4/lib/gcc/sparc-sun-solaris2.10/3.4.4/specs > Configured with: ./configure --prefix=/local/encap/gcc-3.4.4 --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-shared > Thread model: posix > gcc version 3.4.4 > configure:2325: $? = 0 > configure:2327: gcc -V &5 > gcc: `-V' option must have argument > configure:2330: $? = 1 > configure:2353: checking for C compiler default output file name > configure:2356: gcc conftest.c >&5 > configure:2359: $? = 0 > configure:2405: result: a.out > configure:2410: checking whether the C compiler works > configure:2416: ./a.out > configure:2419: $? = 0 > configure:2436: result: yes > configure:2443: checking whether we are cross compiling > configure:2445: result: no > configure:2448: checking for suffix of executables > configure:2450: gcc -o conftest conftest.c >&5 > configure:2453: $? = 0 > configure:2478: result: > configure:2484: checking for suffix of object files > configure:2505: gcc -c conftest.c >&5 > configure:2508: $? = 0 > configure:2530: result: o > configure:2534: checking whether we are using the GNU C compiler > configure:2558: gcc -c conftest.c >&5 > configure:2564: $? = 0 > configure:2568: test -z > || test ! -s conftest.err > configure:2571: $? = 0 > configure:2574: test -s conftest.o > configure:2577: $? = 0 > configure:2590: result: yes > configure:2596: checking whether gcc accepts -g > configure:2617: gcc -c -g conftest.c >&5 > configure:2623: $? = 0 > configure:2627: test -z > || test ! -s conftest.err > configure:2630: $? = 0 > configure:2633: test -s conftest.o > configure:2636: $? = 0 > configure:2647: result: yes > configure:2664: checking for gcc option to accept ANSI C > configure:2734: gcc -c conftest.c >&5 > configure:2740: $? = 0 > configure:2744: test -z > || test ! -s conftest.err > configure:2747: $? = 0 > configure:2750: test -s conftest.o > configure:2753: $? = 0 > configure:2771: result: none needed > configure:2789: gcc -c conftest.c >&5 > conftest.c:2: error: syntax error before "me" > configure:2795: $? = 1 > configure: failed program was: > | #ifndef __cplusplus > | choke me > | #endif > configure:2939: checking for style of include used by make > configure:2967: result: GNU > configure:2995: checking dependency style of gcc > configure:3085: result: gcc3 > configure:3107: checking how to run the C preprocessor > configure:3142: gcc -E conftest.c > configure:3148: $? = 0 > configure:3180: gcc -E conftest.c > conftest.c:11:28: ac_nonexistent.h: No such file or directory > configure:3186: $? = 1 > configure: failed program was: > | /* confdefs.h. */ > | > | #define PACKAGE_NAME "" > | #define PACKAGE_TARNAME "" > | #define PACKAGE_VERSION "" > | #define PACKAGE_STRING "" > | #define PACKAGE_BUGREPORT "" > | #define PACKAGE "EMBOSS" > | #define VERSION "4.0.0" > | /* end confdefs.h. */ > | #include > configure:3225: result: gcc -E > configure:3249: gcc -E conftest.c > configure:3255: $? = 0 > configure:3287: gcc -E conftest.c > conftest.c:11:28: ac_nonexistent.h: No such file or directory > configure:3293: $? = 1 > configure: failed program was: > | /* confdefs.h. */ > | > | #define PACKAGE_NAME "" > | #define PACKAGE_TARNAME "" > | #define PACKAGE_VERSION "" > | #define PACKAGE_STRING "" > | #define PACKAGE_BUGREPORT "" > | #define PACKAGE "EMBOSS" > | #define VERSION "4.0.0" > | /* end confdefs.h. */ > | #include > configure:3596: checking build system type > configure:3614: result: sparc-sun-solaris2.10 > configure:3622: checking host system type > configure:3636: result: sparc-sun-solaris2.10 > configure:3644: checking for a sed that does not truncate output > configure:3698: result: /local/bin/sed > configure:3701: checking for egrep > configure:3711: result: grep -E > configure:3727: checking for ld used by gcc > configure:3794: result: /usr/ccs/bin/ld > configure:3803: checking if the linker (/usr/ccs/bin/ld) is GNU ld > configure:3818: result: no > configure:3823: checking for /usr/ccs/bin/ld option to reload object files > configure:3830: result: -r > configure:3848: checking for BSD-compatible nm > configure:3897: result: /usr/ccs/bin/nm -p > configure:3901: checking whether ln -s works > configure:3905: result: yes > configure:3912: checking how to recognise dependent libraries > configure:4088: result: pass_all > configure:4297: gcc -c -O2 -D__EXTENSIONS__ conftest.c >&5 > configure:4300: $? = 0 > configure:4321: checking for ANSI C header files > configure:4346: gcc -c -O2 -D__EXTENSIONS__ conftest.c >&5 > configure:4352: $? = 0 > configure:4356: test -z > || test ! -s conftest.err > configure:4359: $? = 0 > configure:4362: test -s conftest.o > configure:4365: $? = 0 > configure:4454: gcc -o conftest -O2 -D__EXTENSIONS__ conftest.c >&5 > configure:4457: $? = 0 > configure:4459: ./conftest > configure:4462: $? = 0 > configure:4477: result: yes > configure:4501: checking for sys/types.h > configure:4517: gcc -c -O2 -D__EXTENSIONS__ conftest.c >&5 > configure:4523: $? = 0 > configure:4527: test -z > || test ! -s conftest.err > configure:4530: $? = 0 > configure:4533: test -s conftest.o > configure:4536: $? = 0 > configure:4547: result: yes > configure:4501: checking for sys/stat.h > configure:4517: gcc -c -O2 -D__EXTENSIONS__ conftest.c >&5 > configure:4523: $? = 0 > configure:4527: test -z > || test ! -s conftest.err > configure:4530: $? = 0 > configure:4533: test -s conftest.o > configure:4536: $? = 0 > configure:4547: result: yes > configure:4501: checking for stdlib.h > configure:4517: gcc -c -O2 -D__EXTENSIONS__ conftest.c >&5 > configure:4523: $? = 0 > configure:4527: test -z > || test ! -s conftest.err > configure:4530: $? = 0 > configure:4533: test -s conftest.o > configure:4536: $? = 0 > configure:4547: result: yes > configure:4501: checking for string.h > configure:4517: gcc -c -O2 -D__EXTENSIONS__ conftest.c >&5 > configure:4523: $? = 0 > configure:4527: test -z > || test ! -s conftest.err > configure:4530: $? = 0 > configure:4533: test -s conftest.o > configure:4536: $? = 0 > configure:4547: result: yes > configure:4501: checking for memory.h > configure:4517: gcc -c -O2 -D__EXTENSIONS__ conftest.c >&5 > configure:4523: $? = 0 > configure:4527: test -z > || test ! -s conftest.err > configure:4530: $? = 0 > configure:4533: test -s conftest.o > configure:4536: $? = 0 > configure:4547: result: yes > configure:4501: checking for strings.h > configure:4517: gcc -c -O2 -D__EXTENSIONS__ conftest.c >&5 > configure:4523: $? = 0 > configure:4527: test -z > || test ! -s conftest.err > configure:4530: $? = 0 > configure:4533: test -s conftest.o > configure:4536: $? = 0 > configure:4547: result: yes > configure:4501: checking for inttypes.h > configure:4517: gcc -c -O2 -D__EXTENSIONS__ conftest.c >&5 > configure:4523: $? = 0 > configure:4527: test -z > || test ! -s conftest.err > configure:4530: $? = 0 > configure:4533: test -s conftest.o > configure:4536: $? = 0 > configure:4547: result: yes > configure:4501: checking for stdint.h > configure:4517: gcc -c -O2 -D__EXTENSIONS__ conftest.c >&5 > configure:4523: $? = 0 > configure:4527: test -z > || test ! -s conftest.err > configure:4530: $? = 0 > configure:4533: test -s conftest.o > configure:4536: $? = 0 > configure:4547: result: yes > configure:4501: checking for unistd.h > configure:4517: gcc -c -O2 -D__EXTENSIONS__ conftest.c >&5 > configure:4523: $? = 0 > configure:4527: test -z > || test ! -s conftest.err > configure:4530: $? = 0 > configure:4533: test -s conftest.o > configure:4536: $? = 0 > configure:4547: result: yes > configure:4573: checking dlfcn.h usability > configure:4585: gcc -c -O2 -D__EXTENSIONS__ conftest.c >&5 > configure:4591: $? = 0 > configure:4595: test -z > || test ! -s conftest.err > configure:4598: $? = 0 > configure:4601: test -s conftest.o > configure:4604: $? = 0 > configure:4614: result: yes > configure:4618: checking dlfcn.h presence > configure:4628: gcc -E conftest.c > configure:4634: $? = 0 > configure:4654: result: yes > configure:4689: checking for dlfcn.h > configure:4696: result: yes > configure:4761: checking for g++ > configure:4777: found /local/bin/g++ > configure:4787: result: g++ > configure:4803: checking for C++ compiler version > configure:4806: g++ --version &5 > g++ (GCC) 3.4.4 > Copyright (C) 2004 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > configure:4809: $? = 0 > configure:4811: g++ -v &5 > Reading specs from /local/encap/gcc-3.4.4/lib/gcc/sparc-sun-solaris2.10/3.4.4/specs > Configured with: ./configure --prefix=/local/encap/gcc-3.4.4 --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-shared > Thread model: posix > gcc version 3.4.4 > configure:4814: $? = 0 > configure:4816: g++ -V &5 > g++: `-V' option must have argument > configure:4819: $? = 1 > configure:4822: checking whether we are using the GNU C++ compiler > configure:4846: g++ -c conftest.cc >&5 > configure:4852: $? = 0 > configure:4856: test -z > || test ! -s conftest.err > configure:4859: $? = 0 > configure:4862: test -s conftest.o > configure:4865: $? = 0 > configure:4878: result: yes > configure:4884: checking whether g++ accepts -g > configure:4905: g++ -c -g conftest.cc >&5 > configure:4911: $? = 0 > configure:4915: test -z > || test ! -s conftest.err > configure:4918: $? = 0 > configure:4921: test -s conftest.o > configure:4924: $? = 0 > configure:4935: result: yes > configure:4977: g++ -c -g -O2 conftest.cc >&5 > configure:4983: $? = 0 > configure:4987: test -z > || test ! -s conftest.err > configure:4990: $? = 0 > configure:4993: test -s conftest.o > configure:4996: $? = 0 > configure:5022: g++ -c -g -O2 conftest.cc >&5 > conftest.cc: In function `int main()': > conftest.cc:26: error: `exit' undeclared (first use this function) > conftest.cc:26: error: (Each undeclared identifier is reported only once for each function it appears in.) > configure:5028: $? = 1 > configure: failed program was: > | /* confdefs.h. */ > | > | #define PACKAGE_NAME "" > | #define PACKAGE_TARNAME "" > | #define PACKAGE_VERSION "" > | #define PACKAGE_STRING "" > | #define PACKAGE_BUGREPORT "" > | #define PACKAGE "EMBOSS" > | #define VERSION "4.0.0" > | #define STDC_HEADERS 1 > | #define HAVE_SYS_TYPES_H 1 > | #define HAVE_SYS_STAT_H 1 > | #define HAVE_STDLIB_H 1 > | #define HAVE_STRING_H 1 > | #define HAVE_MEMORY_H 1 > | #define HAVE_STRINGS_H 1 > | #define HAVE_INTTYPES_H 1 > | #define HAVE_STDINT_H 1 > | #define HAVE_UNISTD_H 1 > | #define HAVE_DLFCN_H 1 > | /* end confdefs.h. */ > | > | int > | main () > | { > | exit (42); > | ; > | return 0; > | } > configure:4977: g++ -c -g -O2 conftest.cc >&5 > configure:4983: $? = 0 > configure:4987: test -z > || test ! -s conftest.err > configure:4990: $? = 0 > configure:4993: test -s conftest.o > configure:4996: $? = 0 > configure:5022: g++ -c -g -O2 conftest.cc >&5 > configure:5028: $? = 0 > configure:5032: test -z > || test ! -s conftest.err > configure:5035: $? = 0 > configure:5038: test -s conftest.o > configure:5041: $? = 0 > configure:5066: checking dependency style of g++ > configure:5156: result: gcc3 > configure:5183: checking how to run the C++ preprocessor > configure:5214: g++ -E conftest.cc > configure:5220: $? = 0 > configure:5252: g++ -E conftest.cc > conftest.cc:25:28: ac_nonexistent.h: No such file or directory > configure:5258: $? = 1 > configure: failed program was: > | /* confdefs.h. */ > | > | #define PACKAGE_NAME "" > | #define PACKAGE_TARNAME "" > | #define PACKAGE_VERSION "" > | #define PACKAGE_STRING "" > | #define PACKAGE_BUGREPORT "" > | #define PACKAGE "EMBOSS" > | #define VERSION "4.0.0" > | #define STDC_HEADERS 1 > | #define HAVE_SYS_TYPES_H 1 > | #define HAVE_SYS_STAT_H 1 > | #define HAVE_STDLIB_H 1 > | #define HAVE_STRING_H 1 > | #define HAVE_MEMORY_H 1 > | #define HAVE_STRINGS_H 1 > | #define HAVE_INTTYPES_H 1 > | #define HAVE_STDINT_H 1 > | #define HAVE_UNISTD_H 1 > | #define HAVE_DLFCN_H 1 > | #ifdef __cplusplus > | extern "C" void std::exit (int) throw (); using std::exit; > | #endif > | /* end confdefs.h. */ > | #include > configure:5297: result: g++ -E > configure:5321: g++ -E conftest.cc > configure:5327: $? = 0 > configure:5359: g++ -E conftest.cc > conftest.cc:25:28: ac_nonexistent.h: No such file or directory > configure:5365: $? = 1 > configure: failed program was: > | /* confdefs.h. */ > | > | #define PACKAGE_NAME "" > | #define PACKAGE_TARNAME "" > | #define PACKAGE_VERSION "" > | #define PACKAGE_STRING "" > | #define PACKAGE_BUGREPORT "" > | #define PACKAGE "EMBOSS" > | #define VERSION "4.0.0" > | #define STDC_HEADERS 1 > | #define HAVE_SYS_TYPES_H 1 > | #define HAVE_SYS_STAT_H 1 > | #define HAVE_STDLIB_H 1 > | #define HAVE_STRING_H 1 > | #define HAVE_MEMORY_H 1 > | #define HAVE_STRINGS_H 1 > | #define HAVE_INTTYPES_H 1 > | #define HAVE_STDINT_H 1 > | #define HAVE_UNISTD_H 1 > | #define HAVE_DLFCN_H 1 > | #ifdef __cplusplus > | extern "C" void std::exit (int) throw (); using std::exit; > | #endif > | /* end confdefs.h. */ > | #include > configure:5462: checking for g77 > configure:5478: found /local/bin/g77 > configure:5488: result: g77 > configure:5503: checking for Fortran 77 compiler version > configure:5506: g77 --version &5 > GNU Fortran (GCC) 3.4.4 > Copyright (C) 2004 Free Software Foundation, Inc. > > GNU Fortran comes with NO WARRANTY, to the extent permitted by law. > You may redistribute copies of GNU Fortran > under the terms of the GNU General Public License. > For more information about these matters, see the file named COPYING > or type the command `info -f g77 Copying'. > configure:5509: $? = 0 > configure:5511: g77 -v &5 > Reading specs from /local/encap/gcc-3.4.4/lib/gcc/sparc-sun-solaris2.10/3.4.4/specs > Configured with: ./configure --prefix=/local/encap/gcc-3.4.4 --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-shared > Thread model: posix > gcc version 3.4.4 > configure:5514: $? = 0 > configure:5516: g77 -V &5 > g77: `-V' option must have argument > configure:5519: $? = 1 > configure:5527: checking whether we are using the GNU Fortran 77 compiler > configure:5541: g77 -c conftest.F >&5 > configure:5547: $? = 0 > configure:5551: test -z > || test ! -s conftest.err > configure:5554: $? = 0 > configure:5557: test -s conftest.o > configure:5560: $? = 0 > configure:5573: result: yes > configure:5579: checking whether g77 accepts -g > configure:5591: g77 -c -g conftest.f >&5 > configure:5597: $? = 0 > configure:5601: test -z > || test ! -s conftest.err > configure:5604: $? = 0 > configure:5607: test -s conftest.o > configure:5610: $? = 0 > configure:5622: result: yes > configure:5652: checking the maximum length of command line arguments > configure:5761: result: 262144 > configure:5772: checking command to parse /usr/ccs/bin/nm -p output from gcc object > configure:5877: gcc -c -O2 -D__EXTENSIONS__ conftest.c >&5 > configure:5880: $? = 0 > configure:5884: /usr/ccs/bin/nm -p conftest.o \| sed -n -e 's/^.*[ ]\([BDRT][BDRT]*\)[ ][ ]*\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2 \2/p' \> conftest.nm > configure:5887: $? = 0 > configure:5939: gcc -o conftest -O2 -D__EXTENSIONS__ conftest.c conftstm.o >&5 > configure:5942: $? = 0 > configure:5980: result: ok > configure:5984: checking for objdir > configure:5999: result: .libs > configure:6089: checking for ar > configure:6105: found /usr/ccs/bin/ar > configure:6116: result: ar > configure:6169: checking for ranlib > configure:6185: found /usr/ccs/bin/ranlib > configure:6196: result: ranlib > configure:6249: checking for strip > configure:6265: found /usr/ccs/bin/strip > configure:6276: result: strip > configure:6548: checking if gcc supports -fno-rtti -fno-exceptions > configure:6566: gcc -c -O2 -D__EXTENSIONS__ -fno-rtti -fno-exceptions conftest.c >&5 > cc1: warning: command line option "-fno-rtti" is valid for C++/ObjC++ but not for C > configure:6570: $? = 0 > configure:6583: result: no > configure:6598: checking for gcc option to produce PIC > configure:6808: result: -fPIC > configure:6816: checking if gcc PIC flag -fPIC works > configure:6834: gcc -c -O2 -D__EXTENSIONS__ -fPIC -DPIC conftest.c >&5 > configure:6838: $? = 0 > configure:6851: result: yes > configure:6879: checking if gcc static flag -static works > configure:6907: result: no > configure:6917: checking if gcc supports -c -o file.o > configure:6938: gcc -c -O2 -D__EXTENSIONS__ -o out/conftest2.o conftest.c >&5 > configure:6942: $? = 0 > configure:6964: result: yes > configure:6990: checking whether the gcc linker (/usr/ccs/bin/ld) supports shared libraries > configure:7948: result: yes > configure:7969: checking whether -lc should be explicitly linked in > configure:7974: gcc -c -O2 -D__EXTENSIONS__ conftest.c >&5 > configure:7977: $? = 0 > configure:7992: gcc -shared -Wl,-h -Wl,conftest -o conftest conftest.o -v 2\>\&1 \| grep -lc \>/dev/null 2\>\&1 > configure:7995: $? = 1 > configure:8007: result: yes > configure:8015: checking dynamic linker characteristics > configure:8624: result: solaris2.10 ld.so > configure:8633: checking how to hardcode library paths into programs > configure:8658: result: immediate > configure:8672: checking whether stripping libraries is possible > configure:8693: result: no > configure:9511: checking if libtool supports shared libraries > configure:9513: result: yes > configure:9516: checking whether to build shared libraries > configure:9537: result: yes > configure:9540: checking whether to build static libraries > configure:9544: result: yes > configure:9636: creating libtool > configure:10224: checking for ld used by g++ > configure:10291: result: /usr/ccs/bin/ld > configure:10300: checking if the linker (/usr/ccs/bin/ld) is GNU ld > configure:10315: result: no > configure:10366: checking whether the g++ linker (/usr/ccs/bin/ld) supports shared libraries > configure:11304: result: yes > configure:11322: g++ -c -g -O2 conftest.cpp >&5 > configure:11325: $? = 0 > configure:11444: checking for g++ option to produce PIC > configure:11718: result: -fPIC > configure:11726: checking if g++ PIC flag -fPIC works > configure:11744: g++ -c -g -O2 -fPIC -DPIC conftest.cpp >&5 > configure:11748: $? = 0 > configure:11761: result: yes > configure:11789: checking if g++ static flag -static works > configure:11817: result: no > configure:11827: checking if g++ supports -c -o file.o > configure:11848: g++ -c -g -O2 -o out/conftest2.o conftest.cpp >&5 > configure:11852: $? = 0 > configure:11874: result: yes > configure:11900: checking whether the g++ linker (/usr/ccs/bin/ld) supports shared libraries > configure:11925: result: yes > configure:11992: checking dynamic linker characteristics > configure:12601: result: solaris2.10 ld.so > configure:12610: checking how to hardcode library paths into programs > configure:12635: result: immediate > configure:13161: checking if libtool supports shared libraries > configure:13163: result: yes > configure:13166: checking whether to build shared libraries > configure:13186: result: yes > configure:13189: checking whether to build static libraries > configure:13193: result: yes > configure:13203: checking for g77 option to produce PIC > configure:13413: result: -fPIC > configure:13421: checking if g77 PIC flag -fPIC works > configure:13439: g77 -c -g -O2 -fPIC conftest.f >&5 > configure:13443: $? = 0 > configure:13456: result: yes > configure:13484: checking if g77 static flag -static works > configure:13512: result: no > configure:13522: checking if g77 supports -c -o file.o > configure:13543: g77 -c -g -O2 -o out/conftest2.o conftest.f >&5 > configure:13547: $? = 0 > configure:13569: result: yes > configure:13595: checking whether the g77 linker (/usr/ccs/bin/ld) supports shared libraries > configure:14533: result: yes > configure:14600: checking dynamic linker characteristics > configure:15209: result: solaris2.10 ld.so > configure:15218: checking how to hardcode library paths into programs > configure:15243: result: immediate > configure:18828: checking whether byte ordering is bigendian > configure:18855: gcc -c -O2 -D__EXTENSIONS__ conftest.c >&5 > conftest.c: In function `main': > conftest.c:32: error: `bogus' undeclared (first use in this function) > conftest.c:32: error: (Each undeclared identifier is reported only once > conftest.c:32: error: for each function it appears in.) > conftest.c:32: error: syntax error before "endian" > configure:18861: $? = 1 > configure: failed program was: > | /* confdefs.h. */ > | > | #define PACKAGE_NAME "" > | #define PACKAGE_TARNAME "" > | #define PACKAGE_VERSION "" > | #define PACKAGE_STRING "" > | #define PACKAGE_BUGREPORT "" > | #define PACKAGE "EMBOSS" > | #define VERSION "4.0.0" > | #define STDC_HEADERS 1 > | #define HAVE_SYS_TYPES_H 1 > | #define HAVE_SYS_STAT_H 1 > | #define HAVE_STDLIB_H 1 > | #define HAVE_STRING_H 1 > | #define HAVE_MEMORY_H 1 > | #define HAVE_STRINGS_H 1 > | #define HAVE_INTTYPES_H 1 > | #define HAVE_STDINT_H 1 > | #define HAVE_UNISTD_H 1 > | #define HAVE_DLFCN_H 1 > | #ifdef __cplusplus > | extern "C" void std::exit (int) throw (); using std::exit; > | #endif > | /* end confdefs.h. */ > | #include > | #include > | > | int > | main () > | { > | #if !BYTE_ORDER || !BIG_ENDIAN || !LITTLE_ENDIAN > | bogus endian macros > | #endif > | > | ; > | return 0; > | } > configure:19015: gcc -o conftest -O2 -D__EXTENSIONS__ conftest.c >&5 > configure:19018: $? = 0 > configure:19020: ./conftest > configure:19023: $? = 1 > configure: program exited with status 1 > configure: failed program was: > | /* confdefs.h. */ > | > | #define PACKAGE_NAME "" > | #define PACKAGE_TARNAME "" > | #define PACKAGE_VERSION "" > | #define PACKAGE_STRING "" > | #define PACKAGE_BUGREPORT "" > | #define PACKAGE "EMBOSS" > | #define VERSION "4.0.0" > | #define STDC_HEADERS 1 > | #define HAVE_SYS_TYPES_H 1 > | #define HAVE_SYS_STAT_H 1 > | #define HAVE_STDLIB_H 1 > | #define HAVE_STRING_H 1 > | #define HAVE_MEMORY_H 1 > | #define HAVE_STRINGS_H 1 > | #define HAVE_INTTYPES_H 1 > | #define HAVE_STDINT_H 1 > | #define HAVE_UNISTD_H 1 > | #define HAVE_DLFCN_H 1 > | #ifdef __cplusplus > | extern "C" void std::exit (int) throw (); using std::exit; > | #endif > | /* end confdefs.h. */ > | int > | main () > | { > | /* Are we little or big endian? From Harbison&Steele. */ > | union > | { > | long l; > | char c[sizeof (long)]; > | } u; > | u.l = 1; > | exit (u.c[sizeof (long) - 1] == 1); > | } > configure:19039: result: yes > configure:19089: checking for a BSD-compatible install > configure:19144: result: /local/bin/install -c > configure:19155: checking whether ln -s works > configure:19159: result: yes > configure:19166: checking whether make sets $(MAKE) > configure:19186: result: yes > configure:19236: checking for ranlib > configure:19263: result: ranlib > configure:19276: checking for X > configure:19381: gcc -E -DBENDIAN conftest.c > configure:19387: $? = 0 > configure:19437: gcc -o conftest -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c -lXt >&5 > Undefined first referenced > symbol in file > XrmInitialize /var/tmp//ccIjdzQL.o (symbol belongs to implicit dependency /usr/openwin/lib/libX11.so.4) > ld: fatal: Symbol referencing errors. No output written to conftest > collect2: ld returned 1 exit status > configure:19443: $? = 1 > configure: failed program was: > | /* confdefs.h. */ > | > | #define PACKAGE_NAME "" > | #define PACKAGE_TARNAME "" > | #define PACKAGE_VERSION "" > | #define PACKAGE_STRING "" > | #define PACKAGE_BUGREPORT "" > | #define PACKAGE "EMBOSS" > | #define VERSION "4.0.0" > | #define STDC_HEADERS 1 > | #define HAVE_SYS_TYPES_H 1 > | #define HAVE_SYS_STAT_H 1 > | #define HAVE_STDLIB_H 1 > | #define HAVE_STRING_H 1 > | #define HAVE_MEMORY_H 1 > | #define HAVE_STRINGS_H 1 > | #define HAVE_INTTYPES_H 1 > | #define HAVE_STDINT_H 1 > | #define HAVE_UNISTD_H 1 > | #define HAVE_DLFCN_H 1 > | #ifdef __cplusplus > | extern "C" void std::exit (int) throw (); using std::exit; > | #endif > | /* end confdefs.h. */ > | #include > | int > | main () > | { > | XrmInitialize () > | ; > | return 0; > | } > configure:19506: result: libraries /usr/lib, headers > configure:19530: checking whether -R must be followed by a space > configure:19549: gcc -o conftest -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c -R/usr/lib >&5 > configure:19555: $? = 0 > configure:19559: test -z > || test ! -s conftest.err > configure:19562: $? = 0 > configure:19565: test -s conftest > configure:19568: $? = 0 > configure:19580: result: no > configure:19678: gcc -o conftest -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c -L/usr/lib -R/usr/lib -lX11 >&5 > configure:19684: $? = 0 > configure:19688: test -z > || test ! -s conftest.err > configure:19691: $? = 0 > configure:19694: test -s conftest > configure:19697: $? = 0 > configure:19855: checking for gethostbyname > configure:19912: gcc -o conftest -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c >&5 > Undefined first referenced > symbol in file > gethostbyname /var/tmp//ccy7pKHR.o > ld: fatal: Symbol referencing errors. No output written to conftest > collect2: ld returned 1 exit status > configure:19918: $? = 1 > configure: failed program was: > | /* confdefs.h. */ > | > | #define PACKAGE_NAME "" > | #define PACKAGE_TARNAME "" > | #define PACKAGE_VERSION "" > | #define PACKAGE_STRING "" > | #define PACKAGE_BUGREPORT "" > | #define PACKAGE "EMBOSS" > | #define VERSION "4.0.0" > | #define STDC_HEADERS 1 > | #define HAVE_SYS_TYPES_H 1 > | #define HAVE_SYS_STAT_H 1 > | #define HAVE_STDLIB_H 1 > | #define HAVE_STRING_H 1 > | #define HAVE_MEMORY_H 1 > | #define HAVE_STRINGS_H 1 > | #define HAVE_INTTYPES_H 1 > | #define HAVE_STDINT_H 1 > | #define HAVE_UNISTD_H 1 > | #define HAVE_DLFCN_H 1 > | #ifdef __cplusplus > | extern "C" void std::exit (int) throw (); using std::exit; > | #endif > | /* end confdefs.h. */ > | /* Define gethostbyname to an innocuous variant, in case declares gethostbyname. > | For example, HP-UX 11i declares gettimeofday. */ > | #define gethostbyname innocuous_gethostbyname > | > | /* System header to define __stub macros and hopefully few prototypes, > | which can conflict with char gethostbyname (); below. > | Prefer to if __STDC__ is defined, since > | exists even on freestanding compilers. */ > | > | #ifdef __STDC__ > | # include > | #else > | # include > | #endif > | > | #undef gethostbyname > | > | /* Override any gcc2 internal prototype to avoid an error. */ > | #ifdef __cplusplus > | extern "C" > | { > | #endif > | /* We use char because int might match the return type of a gcc2 > | builtin and then its argument prototype would still apply. */ > | char gethostbyname (); > | /* The GNU C library defines this for functions which it implements > | to always fail with ENOSYS. Some functions are actually named > | something starting with __ and the normal name is an alias. */ > | #if defined (__stub_gethostbyname) || defined (__stub___gethostbyname) > | choke me > | #else > | char (*f) () = gethostbyname; > | #endif > | #ifdef __cplusplus > | } > | #endif > | > | int > | main () > | { > | return f != gethostbyname; > | ; > | return 0; > | } > configure:19943: result: no > configure:19947: checking for gethostbyname in -lnsl > configure:19977: gcc -o conftest -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c -lnsl >&5 > configure:19983: $? = 0 > configure:19987: test -z > || test ! -s conftest.err > configure:19990: $? = 0 > configure:19993: test -s conftest > configure:19996: $? = 0 > configure:20009: result: yes > configure:20094: checking for connect > configure:20151: gcc -o conftest -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c >&5 > Undefined first referenced > symbol in file > connect /var/tmp//cc2mi2rV.o > ld: fatal: Symbol referencing errors. No output written to conftest > collect2: ld returned 1 exit status > configure:20157: $? = 1 > configure: failed program was: > | /* confdefs.h. */ > | > | #define PACKAGE_NAME "" > | #define PACKAGE_TARNAME "" > | #define PACKAGE_VERSION "" > | #define PACKAGE_STRING "" > | #define PACKAGE_BUGREPORT "" > | #define PACKAGE "EMBOSS" > | #define VERSION "4.0.0" > | #define STDC_HEADERS 1 > | #define HAVE_SYS_TYPES_H 1 > | #define HAVE_SYS_STAT_H 1 > | #define HAVE_STDLIB_H 1 > | #define HAVE_STRING_H 1 > | #define HAVE_MEMORY_H 1 > | #define HAVE_STRINGS_H 1 > | #define HAVE_INTTYPES_H 1 > | #define HAVE_STDINT_H 1 > | #define HAVE_UNISTD_H 1 > | #define HAVE_DLFCN_H 1 > | #ifdef __cplusplus > | extern "C" void std::exit (int) throw (); using std::exit; > | #endif > | /* end confdefs.h. */ > | /* Define connect to an innocuous variant, in case declares connect. > | For example, HP-UX 11i declares gettimeofday. */ > | #define connect innocuous_connect > | > | /* System header to define __stub macros and hopefully few prototypes, > | which can conflict with char connect (); below. > | Prefer to if __STDC__ is defined, since > | exists even on freestanding compilers. */ > | > | #ifdef __STDC__ > | # include > | #else > | # include > | #endif > | > | #undef connect > | > | /* Override any gcc2 internal prototype to avoid an error. */ > | #ifdef __cplusplus > | extern "C" > | { > | #endif > | /* We use char because int might match the return type of a gcc2 > | builtin and then its argument prototype would still apply. */ > | char connect (); > | /* The GNU C library defines this for functions which it implements > | to always fail with ENOSYS. Some functions are actually named > | something starting with __ and the normal name is an alias. */ > | #if defined (__stub_connect) || defined (__stub___connect) > | choke me > | #else > | char (*f) () = connect; > | #endif > | #ifdef __cplusplus > | } > | #endif > | > | int > | main () > | { > | return f != connect; > | ; > | return 0; > | } > configure:20182: result: no > configure:20186: checking for connect in -lsocket > configure:20216: gcc -o conftest -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c -lsocket -lnsl >&5 > configure:20222: $? = 0 > configure:20226: test -z > || test ! -s conftest.err > configure:20229: $? = 0 > configure:20232: test -s conftest > configure:20235: $? = 0 > configure:20248: result: yes > configure:20257: checking for remove > configure:20314: gcc -o conftest -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c >&5 > configure:20320: $? = 0 > configure:20324: test -z > || test ! -s conftest.err > configure:20327: $? = 0 > configure:20330: test -s conftest > configure:20333: $? = 0 > configure:20345: result: yes > configure:20420: checking for shmat > configure:20477: gcc -o conftest -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c >&5 > configure:20483: $? = 0 > configure:20487: test -z > || test ! -s conftest.err > configure:20490: $? = 0 > configure:20493: test -s conftest > configure:20496: $? = 0 > configure:20508: result: yes > configure:20592: checking for IceConnectionNumber in -lICE > configure:20622: gcc -o conftest -O2 -D__EXTENSIONS__ -DBENDIAN -L/usr/lib conftest.c -lICE -lsocket -lnsl >&5 > configure:20628: $? = 0 > configure:20632: test -z > || test ! -s conftest.err > configure:20635: $? = 0 > configure:20638: test -s conftest > configure:20641: $? = 0 > configure:20654: result: yes > configure:20672: checking for dirent.h that defines DIR > configure:20696: gcc -c -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c >&5 > configure:20702: $? = 0 > configure:20706: test -z > || test ! -s conftest.err > configure:20709: $? = 0 > configure:20712: test -s conftest.o > configure:20715: $? = 0 > configure:20726: result: yes > configure:20739: checking for library containing opendir > configure:20769: gcc -o conftest -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c >&5 > configure:20775: $? = 0 > configure:20779: test -z > || test ! -s conftest.err > configure:20782: $? = 0 > configure:20785: test -s conftest > configure:20788: $? = 0 > configure:20858: result: none required > configure:20994: checking for ANSI C header files > configure:21150: result: yes > configure:21166: checking for unistd.h > configure:21171: result: yes > configure:21312: checking for an ANSI C-conforming const > configure:21379: gcc -c -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c >&5 > configure:21385: $? = 0 > configure:21389: test -z > || test ! -s conftest.err > configure:21392: $? = 0 > configure:21395: test -s conftest.o > configure:21398: $? = 0 > configure:21409: result: yes > configure:21419: checking for pid_t > configure:21443: gcc -c -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c >&5 > configure:21449: $? = 0 > configure:21453: test -z > || test ! -s conftest.err > configure:21456: $? = 0 > configure:21459: test -s conftest.o > configure:21462: $? = 0 > configure:21473: result: yes > configure:21485: checking for size_t > configure:21509: gcc -c -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c >&5 > configure:21515: $? = 0 > configure:21519: test -z > || test ! -s conftest.err > configure:21522: $? = 0 > configure:21525: test -s conftest.o > configure:21528: $? = 0 > configure:21539: result: yes > configure:21551: checking whether struct tm is in sys/time.h or time.h > configure:21574: gcc -c -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c >&5 > configure:21580: $? = 0 > configure:21584: test -z > || test ! -s conftest.err > configure:21587: $? = 0 > configure:21590: test -s conftest.o > configure:21593: $? = 0 > configure:21604: result: time.h > configure:21615: checking whether getpgrp requires zero arguments > configure:21637: gcc -c -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c >&5 > conftest.c: In function `main': > conftest.c:65: error: too many arguments to function `getpgrp' > configure:21643: $? = 1 > configure: failed program was: > | /* confdefs.h. */ > | > | #define PACKAGE_NAME "" > | #define PACKAGE_TARNAME "" > | #define PACKAGE_VERSION "" > | #define PACKAGE_STRING "" > | #define PACKAGE_BUGREPORT "" > | #define PACKAGE "EMBOSS" > | #define VERSION "4.0.0" > | #define STDC_HEADERS 1 > | #define HAVE_SYS_TYPES_H 1 > | #define HAVE_SYS_STAT_H 1 > | #define HAVE_STDLIB_H 1 > | #define HAVE_STRING_H 1 > | #define HAVE_MEMORY_H 1 > | #define HAVE_STRINGS_H 1 > | #define HAVE_INTTYPES_H 1 > | #define HAVE_STDINT_H 1 > | #define HAVE_UNISTD_H 1 > | #define HAVE_DLFCN_H 1 > | #ifdef __cplusplus > | extern "C" void std::exit (int) throw (); using std::exit; > | #endif > | #define HAVE_DIRENT_H 1 > | #define STDC_HEADERS 1 > | #define HAVE_UNISTD_H 1 > | /* end confdefs.h. */ > | #include > | #if HAVE_SYS_TYPES_H > | # include > | #endif > | #if HAVE_SYS_STAT_H > | # include > | #endif > | #if STDC_HEADERS > | # include > | # include > | #else > | # if HAVE_STDLIB_H > | # include > | # endif > | #endif > | #if HAVE_STRING_H > | # if !STDC_HEADERS && HAVE_MEMORY_H > | # include > | # endif > | # include > | #endif > | #if HAVE_STRINGS_H > | # include > | #endif > | #if HAVE_INTTYPES_H > | # include > | #else > | # if HAVE_STDINT_H > | # include > | # endif > | #endif > | #if HAVE_UNISTD_H > | # include > | #endif > | int > | main () > | { > | getpgrp (0); > | ; > | return 0; > | } > configure:21668: result: yes > configure:21682: checking for strftime > configure:21739: gcc -o conftest -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c >&5 > conftest.c:53: warning: conflicting types for built-in function 'strftime' > configure:21745: $? = 0 > configure:21749: test -z > || test ! -s conftest.err > configure:21752: $? = 0 > configure:21755: test -s conftest > configure:21758: $? = 0 > configure:21770: result: yes > configure:21860: checking for unistd.h > configure:21865: result: yes > configure:21869: checking vfork.h usability > configure:21881: gcc -c -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c >&5 > conftest.c:65:19: vfork.h: No such file or directory > configure:21887: $? = 1 > configure: failed program was: > | /* confdefs.h. */ > | > | #define PACKAGE_NAME "" > | #define PACKAGE_TARNAME "" > | #define PACKAGE_VERSION "" > | #define PACKAGE_STRING "" > | #define PACKAGE_BUGREPORT "" > | #define PACKAGE "EMBOSS" > | #define VERSION "4.0.0" > | #define STDC_HEADERS 1 > | #define HAVE_SYS_TYPES_H 1 > | #define HAVE_SYS_STAT_H 1 > | #define HAVE_STDLIB_H 1 > | #define HAVE_STRING_H 1 > | #define HAVE_MEMORY_H 1 > | #define HAVE_STRINGS_H 1 > | #define HAVE_INTTYPES_H 1 > | #define HAVE_STDINT_H 1 > | #define HAVE_UNISTD_H 1 > | #define HAVE_DLFCN_H 1 > | #ifdef __cplusplus > | extern "C" void std::exit (int) throw (); using std::exit; > | #endif > | #define HAVE_DIRENT_H 1 > | #define STDC_HEADERS 1 > | #define HAVE_UNISTD_H 1 > | #define GETPGRP_VOID 1 > | #define HAVE_STRFTIME 1 > | #define HAVE_UNISTD_H 1 > | /* end confdefs.h. */ > | #include > | #if HAVE_SYS_TYPES_H > | # include > | #endif > | #if HAVE_SYS_STAT_H > | # include > | #endif > | #if STDC_HEADERS > | # include > | # include > | #else > | # if HAVE_STDLIB_H > | # include > | # endif > | #endif > | #if HAVE_STRING_H > | # if !STDC_HEADERS && HAVE_MEMORY_H > | # include > | # endif > | # include > | #endif > | #if HAVE_STRINGS_H > | # include > | #endif > | #if HAVE_INTTYPES_H > | # include > | #else > | # if HAVE_STDINT_H > | # include > | # endif > | #endif > | #if HAVE_UNISTD_H > | # include > | #endif > | #include > configure:21910: result: no > configure:21914: checking vfork.h presence > configure:21924: gcc -E -DBENDIAN conftest.c > conftest.c:31:19: vfork.h: No such file or directory > configure:21930: $? = 1 > configure: failed program was: > | /* confdefs.h. */ > | > | #define PACKAGE_NAME "" > | #define PACKAGE_TARNAME "" > | #define PACKAGE_VERSION "" > | #define PACKAGE_STRING "" > | #define PACKAGE_BUGREPORT "" > | #define PACKAGE "EMBOSS" > | #define VERSION "4.0.0" > | #define STDC_HEADERS 1 > | #define HAVE_SYS_TYPES_H 1 > | #define HAVE_SYS_STAT_H 1 > | #define HAVE_STDLIB_H 1 > | #define HAVE_STRING_H 1 > | #define HAVE_MEMORY_H 1 > | #define HAVE_STRINGS_H 1 > | #define HAVE_INTTYPES_H 1 > | #define HAVE_STDINT_H 1 > | #define HAVE_UNISTD_H 1 > | #define HAVE_DLFCN_H 1 > | #ifdef __cplusplus > | extern "C" void std::exit (int) throw (); using std::exit; > | #endif > | #define HAVE_DIRENT_H 1 > | #define STDC_HEADERS 1 > | #define HAVE_UNISTD_H 1 > | #define GETPGRP_VOID 1 > | #define HAVE_STRFTIME 1 > | #define HAVE_UNISTD_H 1 > | /* end confdefs.h. */ > | #include > configure:21950: result: no > configure:21985: checking for vfork.h > configure:21992: result: no > configure:22010: checking for fork > configure:22067: gcc -o conftest -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c >&5 > configure:22073: $? = 0 > configure:22077: test -z > || test ! -s conftest.err > configure:22080: $? = 0 > configure:22083: test -s conftest > configure:22086: $? = 0 > configure:22098: result: yes > configure:22010: checking for vfork > configure:22067: gcc -o conftest -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c >&5 > configure:22073: $? = 0 > configure:22077: test -z > || test ! -s conftest.err > configure:22080: $? = 0 > configure:22083: test -s conftest > configure:22086: $? = 0 > configure:22098: result: yes > configure:22109: checking for working fork > configure:22132: gcc -o conftest -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c >&5 > configure:22135: $? = 0 > configure:22137: ./conftest > configure:22140: $? = 0 > configure:22154: result: yes > configure:22175: checking for working vfork > configure:22308: result: yes > configure:22343: checking for vprintf > configure:22400: gcc -o conftest -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c >&5 > conftest.c:59: warning: conflicting types for built-in function 'vprintf' > configure:22406: $? = 0 > configure:22410: test -z > || test ! -s conftest.err > configure:22413: $? = 0 > configure:22416: test -s conftest > configure:22419: $? = 0 > configure:22431: result: yes > configure:22438: checking for _doprnt > configure:22495: gcc -o conftest -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c >&5 > configure:22501: $? = 0 > configure:22505: test -z > || test ! -s conftest.err > configure:22508: $? = 0 > configure:22511: test -s conftest > configure:22514: $? = 0 > configure:22526: result: yes > configure:22545: checking for memmove > configure:22602: gcc -o conftest -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c >&5 > conftest.c:61: warning: conflicting types for built-in function 'memmove' > configure:22608: $? = 0 > configure:22612: test -z > || test ! -s conftest.err > configure:22615: $? = 0 > configure:22618: test -s conftest > configure:22621: $? = 0 > configure:22633: result: yes > configure:22652: checking for gethostbyname in -lc > configure:22682: gcc -o conftest -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c -lc >&5 > Undefined first referenced > symbol in file > gethostbyname /var/tmp//ccSBeEVg.o > ld: fatal: Symbol referencing errors. No output written to conftest > collect2: ld returned 1 exit status > configure:22688: $? = 1 > configure: failed program was: > | /* confdefs.h. */ > | > | #define PACKAGE_NAME "" > | #define PACKAGE_TARNAME "" > | #define PACKAGE_VERSION "" > | #define PACKAGE_STRING "" > | #define PACKAGE_BUGREPORT "" > | #define PACKAGE "EMBOSS" > | #define VERSION "4.0.0" > | #define STDC_HEADERS 1 > | #define HAVE_SYS_TYPES_H 1 > | #define HAVE_SYS_STAT_H 1 > | #define HAVE_STDLIB_H 1 > | #define HAVE_STRING_H 1 > | #define HAVE_MEMORY_H 1 > | #define HAVE_STRINGS_H 1 > | #define HAVE_INTTYPES_H 1 > | #define HAVE_STDINT_H 1 > | #define HAVE_UNISTD_H 1 > | #define HAVE_DLFCN_H 1 > | #ifdef __cplusplus > | extern "C" void std::exit (int) throw (); using std::exit; > | #endif > | #define HAVE_DIRENT_H 1 > | #define STDC_HEADERS 1 > | #define HAVE_UNISTD_H 1 > | #define GETPGRP_VOID 1 > | #define HAVE_STRFTIME 1 > | #define HAVE_UNISTD_H 1 > | #define HAVE_FORK 1 > | #define HAVE_VFORK 1 > | #define HAVE_WORKING_VFORK 1 > | #define HAVE_WORKING_FORK 1 > | #define HAVE_VPRINTF 1 > | #define HAVE_DOPRNT 1 > | #define HAVE_MEMMOVE 1 > | /* end confdefs.h. */ > | > | /* Override any gcc2 internal prototype to avoid an error. */ > | #ifdef __cplusplus > | extern "C" > | #endif > | /* We use char because int might match the return type of a gcc2 > | builtin and then its argument prototype would still apply. */ > | char gethostbyname (); > | int > | main () > | { > | gethostbyname (); > | ; > | return 0; > | } > configure:22714: result: no > configure:22722: checking for socket in -lc > configure:22752: gcc -o conftest -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c -lc -lnsl >&5 > Undefined first referenced > symbol in file > socket /var/tmp//cc6qIEXF.o > ld: fatal: Symbol referencing errors. No output written to conftest > collect2: ld returned 1 exit status > configure:22758: $? = 1 > configure: failed program was: > | /* confdefs.h. */ > | > | #define PACKAGE_NAME "" > | #define PACKAGE_TARNAME "" > | #define PACKAGE_VERSION "" > | #define PACKAGE_STRING "" > | #define PACKAGE_BUGREPORT "" > | #define PACKAGE "EMBOSS" > | #define VERSION "4.0.0" > | #define STDC_HEADERS 1 > | #define HAVE_SYS_TYPES_H 1 > | #define HAVE_SYS_STAT_H 1 > | #define HAVE_STDLIB_H 1 > | #define HAVE_STRING_H 1 > | #define HAVE_MEMORY_H 1 > | #define HAVE_STRINGS_H 1 > | #define HAVE_INTTYPES_H 1 > | #define HAVE_STDINT_H 1 > | #define HAVE_UNISTD_H 1 > | #define HAVE_DLFCN_H 1 > | #ifdef __cplusplus > | extern "C" void std::exit (int) throw (); using std::exit; > | #endif > | #define HAVE_DIRENT_H 1 > | #define STDC_HEADERS 1 > | #define HAVE_UNISTD_H 1 > | #define GETPGRP_VOID 1 > | #define HAVE_STRFTIME 1 > | #define HAVE_UNISTD_H 1 > | #define HAVE_FORK 1 > | #define HAVE_VFORK 1 > | #define HAVE_WORKING_VFORK 1 > | #define HAVE_WORKING_FORK 1 > | #define HAVE_VPRINTF 1 > | #define HAVE_DOPRNT 1 > | #define HAVE_MEMMOVE 1 > | /* end confdefs.h. */ > | > | /* Override any gcc2 internal prototype to avoid an error. */ > | #ifdef __cplusplus > | extern "C" > | #endif > | /* We use char because int might match the return type of a gcc2 > | builtin and then its argument prototype would still apply. */ > | char socket (); > | int > | main () > | { > | socket (); > | ; > | return 0; > | } > configure:22784: result: no > configure:22793: checking for main in -lm > configure:22817: gcc -o conftest -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c -lm -lnsl -lsocket >&5 > configure:22823: $? = 0 > configure:22827: test -z > || test ! -s conftest.err > configure:22830: $? = 0 > configure:22833: test -s conftest > configure:22836: $? = 0 > configure:22849: result: yes > configure:22942: checking if docroot is given > configure:22955: result: no > configure:22963: checking if gcc profiling is selected > configure:22977: result: no > configure:22987: checking if java include directory given > configure:23057: result: no > configure:23072: checking if java OS include directory given > configure:23094: result: no > configure:23113: checking if png driver is wanted > configure:23120: result: yes > configure:23156: checking for libiconv_close in -liconv > configure:23186: gcc -o conftest -O2 -D__EXTENSIONS__ -DBENDIAN -I/local/include -L/local/lib conftest.c -liconv -L/local/lib -liconv -lm -lnsl -lsocket >&5 > configure:23192: $? = 0 > configure:23196: test -z > || test ! -s conftest.err > configure:23199: $? = 0 > configure:23202: test -s conftest > configure:23205: $? = 0 > configure:23218: result: yes > configure:23239: checking for inflateEnd in -lz > configure:23269: gcc -o conftest -O2 -D__EXTENSIONS__ -DBENDIAN -I/local/include -L/local/lib -L/local/lib -liconv -R/local/lib conftest.c -lz -L/local/lib -lz -lm -lnsl -lsocket >&5 > configure:23275: $? = 0 > configure:23279: test -z > || test ! -s conftest.err > configure:23282: $? = 0 > configure:23285: test -s conftest > configure:23288: $? = 0 > configure:23301: result: yes > configure:23315: checking for png_destroy_read_struct in -lpng > configure:23345: gcc -o conftest -O2 -D__EXTENSIONS__ -DBENDIAN -I/local/include -L/local/lib -L/local/lib -liconv -R/local/lib conftest.c -lpng -L/local/lib -lz -lm -lnsl -lsocket >&5 > configure:23351: $? = 0 > configure:23355: test -z > || test ! -s conftest.err > configure:23358: $? = 0 > configure:23361: test -s conftest > configure:23364: $? = 0 > configure:23377: result: yes > configure:23394: checking for gdImageCreateFromPng in -lgd > configure:23424: gcc -o conftest -O2 -D__EXTENSIONS__ -DBENDIAN -I/local/include -L/local/lib -L/local/lib -liconv -R/local/lib conftest.c -lgd -L/local/lib -lgd -lpng -lz -lm -lm -lnsl -lsocket >&5 > configure:23430: $? = 0 > configure:23434: test -z > || test ! -s conftest.err > configure:23437: $? = 0 > configure:23440: test -s conftest > configure:23443: $? = 0 > configure:23456: result: yes > configure:23536: checking if any authorisation type is given > configure:23708: result: no > configure:23729: checking for gdome2 > configure:23747: result: no > configure:23756: checking if Linux x86_64 > configure:23770: result: no > configure:23831: checking for large file support > configure:23866: result: done > configure:23883: checking for purify > configure:23897: result: no > configure:24011: checking if any threading type is given > configure:24077: result: no > configure:24288: creating ./config.status > > ## ---------------------- ## > ## Running config.status. ## > ## ---------------------- ## > > This file was extended by config.status, which was > generated by GNU Autoconf 2.59. Invocation command line was > > CONFIG_FILES = > CONFIG_HEADERS = > CONFIG_LINKS = > CONFIG_COMMANDS = > $ ./config.status > > on helix > > config.status:801: creating plplot/Makefile > config.status:801: creating plplot/lib/Makefile > config.status:801: creating nucleus/Makefile > config.status:801: creating ajax/Makefile > config.status:801: creating emboss/Makefile > config.status:801: creating emboss/acd/Makefile > config.status:801: creating test/Makefile > config.status:801: creating test/data/Makefile > config.status:801: creating test/embl/Makefile > config.status:801: creating test/genbank/Makefile > config.status:801: creating test/gb/Makefile > config.status:801: creating test/pir/Makefile > config.status:801: creating test/swiss/Makefile > config.status:801: creating test/swnew/Makefile > config.status:801: creating test/wormpep/Makefile > config.status:801: creating emboss/data/Makefile > config.status:801: creating emboss/data/AAINDEX/Makefile > config.status:801: creating emboss/data/CODONS/Makefile > config.status:801: creating emboss/data/REBASE/Makefile > config.status:801: creating emboss/data/PRINTS/Makefile > config.status:801: creating emboss/data/PROSITE/Makefile > config.status:801: creating doc/Makefile > config.status:801: creating doc/manuals/Makefile > config.status:801: creating doc/tutorials/Makefile > config.status:801: creating doc/programs/Makefile > config.status:801: creating doc/programs/html/Makefile > config.status:801: creating doc/programs/text/Makefile > config.status:801: creating jemboss/Makefile > config.status:801: creating jemboss/api/Makefile > config.status:801: creating jemboss/api/org/Makefile > config.status:801: creating jemboss/api/org/emboss/Makefile > config.status:801: creating jemboss/api/org/emboss/jemboss/Makefile > config.status:801: creating jemboss/api/org/emboss/jemboss/gui/Makefile > config.status:801: creating jemboss/api/org/emboss/jemboss/gui/filetree/Makefile > config.status:801: creating jemboss/api/org/emboss/jemboss/gui/form/Makefile > config.status:801: creating jemboss/api/org/emboss/jemboss/gui/sequenceChooser/Makefile > config.status:801: creating jemboss/api/org/emboss/jemboss/gui/startup/Makefile > config.status:801: creating jemboss/api/org/emboss/jemboss/parser/Makefile > config.status:801: creating jemboss/api/org/emboss/jemboss/parser/acd/Makefile > config.status:801: creating jemboss/api/org/emboss/jemboss/programs/Makefile > config.status:801: creating jemboss/api/org/emboss/jemboss/soap/Makefile > config.status:801: creating jemboss/images/Makefile > config.status:801: creating jemboss/lib/Makefile > config.status:801: creating jemboss/lib/axis/Makefile > config.status:801: creating jemboss/org/Makefile > config.status:801: creating jemboss/org/emboss/Makefile > config.status:801: creating jemboss/org/emboss/jemboss/Makefile > config.status:801: creating jemboss/org/emboss/jemboss/graphics/Makefile > config.status:801: creating jemboss/org/emboss/jemboss/gui/Makefile > config.status:801: creating jemboss/org/emboss/jemboss/gui/filetree/Makefile > config.status:801: creating jemboss/org/emboss/jemboss/gui/form/Makefile > config.status:801: creating jemboss/org/emboss/jemboss/gui/startup/Makefile > config.status:801: creating jemboss/org/emboss/jemboss/gui/sequenceChooser/Makefile > config.status:801: creating jemboss/org/emboss/jemboss/parser/Makefile > config.status:801: creating jemboss/org/emboss/jemboss/parser/acd/Makefile > config.status:801: creating jemboss/org/emboss/jemboss/programs/Makefile > config.status:801: creating jemboss/org/emboss/jemboss/server/Makefile > config.status:801: creating jemboss/org/emboss/jemboss/soap/Makefile > config.status:801: creating jemboss/org/emboss/jemboss/editor/Makefile > config.status:801: creating jemboss/org/emboss/jemboss/draw/Makefile > config.status:801: creating jemboss/resources/Makefile > config.status:801: creating jemboss/utils/Makefile > config.status:801: creating Makefile > config.status:984: executing depfiles commands > > ## ---------------- ## > ## Cache variables. ## > ## ---------------- ## > > ac_cv_build=sparc-sun-solaris2.10 > ac_cv_build_alias=sparc-sun-solaris2.10 > ac_cv_c_bigendian=yes > ac_cv_c_compiler_gnu=yes > ac_cv_c_const=yes > ac_cv_cxx_compiler_gnu=yes > ac_cv_env_CC_set= > ac_cv_env_CC_value= > ac_cv_env_CFLAGS_set= > ac_cv_env_CFLAGS_value= > ac_cv_env_CPPFLAGS_set= > ac_cv_env_CPPFLAGS_value= > ac_cv_env_CPP_set= > ac_cv_env_CPP_value= > ac_cv_env_CXXCPP_set= > ac_cv_env_CXXCPP_value= > ac_cv_env_CXXFLAGS_set= > ac_cv_env_CXXFLAGS_value= > ac_cv_env_CXX_set= > ac_cv_env_CXX_value= > ac_cv_env_F77_set= > ac_cv_env_F77_value= > ac_cv_env_FFLAGS_set= > ac_cv_env_FFLAGS_value= > ac_cv_env_LDFLAGS_set= > ac_cv_env_LDFLAGS_value= > ac_cv_env_build_alias_set= > ac_cv_env_build_alias_value= > ac_cv_env_host_alias_set= > ac_cv_env_host_alias_value= > ac_cv_env_target_alias_set= > ac_cv_env_target_alias_value= > ac_cv_exeext= > ac_cv_f77_compiler_gnu=yes > ac_cv_func__doprnt=yes > ac_cv_func_connect=no > ac_cv_func_fork=yes > ac_cv_func_fork_works=yes > ac_cv_func_gethostbyname=no > ac_cv_func_getpgrp_void=yes > ac_cv_func_memmove=yes > ac_cv_func_remove=yes > ac_cv_func_shmat=yes > ac_cv_func_strftime=yes > ac_cv_func_vfork=yes > ac_cv_func_vfork_works=yes > ac_cv_func_vprintf=yes > ac_cv_have_x='have_x=yes ac_x_includes= ac_x_libraries=/usr/lib' > ac_cv_header_dirent_dirent_h=yes > ac_cv_header_dlfcn_h=yes > ac_cv_header_inttypes_h=yes > ac_cv_header_memory_h=yes > ac_cv_header_stdc=yes > ac_cv_header_stdint_h=yes > ac_cv_header_stdlib_h=yes > ac_cv_header_string_h=yes > ac_cv_header_strings_h=yes > ac_cv_header_sys_stat_h=yes > ac_cv_header_sys_types_h=yes > ac_cv_header_unistd_h=yes > ac_cv_header_vfork_h=no > ac_cv_host=sparc-sun-solaris2.10 > ac_cv_host_alias=sparc-sun-solaris2.10 > ac_cv_lib_ICE_IceConnectionNumber=yes > ac_cv_lib_c_gethostbyname=no > ac_cv_lib_c_socket=no > ac_cv_lib_gd_gdImageCreateFromPng=yes > ac_cv_lib_iconv_libiconv_close=yes > ac_cv_lib_m_main=yes > ac_cv_lib_nsl_gethostbyname=yes > ac_cv_lib_png_png_destroy_read_struct=yes > ac_cv_lib_socket_connect=yes > ac_cv_lib_z_inflateEnd=yes > ac_cv_objext=o > ac_cv_path_install='/local/bin/install -c' > ac_cv_prog_AWK=gawk > ac_cv_prog_CPP='gcc -E' > ac_cv_prog_CXXCPP='g++ -E' > ac_cv_prog_ac_ct_AR=ar > ac_cv_prog_ac_ct_CC=gcc > ac_cv_prog_ac_ct_CXX=g++ > ac_cv_prog_ac_ct_F77=g77 > ac_cv_prog_ac_ct_RANLIB=ranlib > ac_cv_prog_ac_ct_STRIP=strip > ac_cv_prog_cc_g=yes > ac_cv_prog_cc_stdc= > ac_cv_prog_cxx_g=yes > ac_cv_prog_egrep='grep -E' > ac_cv_prog_f77_g=yes > ac_cv_prog_make_make_set=yes > ac_cv_search_opendir='none required' > ac_cv_struct_tm=time.h > ac_cv_type_pid_t=yes > ac_cv_type_size_t=yes > am_cv_CC_dependencies_compiler_type=gcc3 > am_cv_CXX_dependencies_compiler_type=gcc3 > lt_cv_deplibs_check_method=pass_all > lt_cv_file_magic_cmd='$MAGIC_CMD' > lt_cv_file_magic_test_file= > lt_cv_ld_reload_flag=-r > lt_cv_objdir=.libs > lt_cv_path_LD=/usr/ccs/bin/ld > lt_cv_path_LDCXX=/usr/ccs/bin/ld > lt_cv_path_NM='/usr/ccs/bin/nm -p' > lt_cv_path_SED=/local/bin/sed > lt_cv_prog_compiler_c_o=yes > lt_cv_prog_compiler_c_o_CXX=yes > lt_cv_prog_compiler_c_o_F77=yes > lt_cv_prog_compiler_rtti_exceptions=no > lt_cv_prog_gnu_ld=no > lt_cv_prog_gnu_ldcxx=no > lt_cv_sys_global_symbol_pipe='sed -n -e '\''s/^.*[ ]\([BDRT][BDRT]*\)[ ][ ]*\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2 \2/p'\''' > lt_cv_sys_global_symbol_to_c_name_address='sed -n -e '\''s/^: \([^ ]*\) $/ {\"\1\", (lt_ptr) 0},/p'\'' -e '\''s/^[BCDEGRST] \([^ ]*\) \([^ ]*\)$/ {"\2", (lt_ptr) \&\2},/p'\''' > lt_cv_sys_global_symbol_to_cdecl='sed -n -e '\''s/^. .* \(.*\)$/extern int \1;/p'\''' > lt_cv_sys_max_cmd_len=262144 > lt_lt_cv_prog_compiler_c_o='"yes"' > lt_lt_cv_prog_compiler_c_o_CXX='"yes"' > lt_lt_cv_prog_compiler_c_o_F77='"yes"' > lt_lt_cv_sys_global_symbol_pipe='"sed -n -e '\''s/^.*[ ]\\([BDRT][BDRT]*\\)[ ][ ]*\\([_A-Za-z][_A-Za-z0-9]*\\)\$/\\1 \\2 \\2/p'\''"' > lt_lt_cv_sys_global_symbol_to_c_name_address='"sed -n -e '\''s/^: \\([^ ]*\\) \$/ {\\\"\\1\\\", (lt_ptr) 0},/p'\'' -e '\''s/^[BCDEGRST] \\([^ ]*\\) \\([^ ]*\\)\$/ {\"\\2\", (lt_ptr) \\&\\2},/p'\''"' > lt_lt_cv_sys_global_symbol_to_cdecl='"sed -n -e '\''s/^. .* \\(.*\\)\$/extern int \\1;/p'\''"' > > ## ----------------- ## > ## Output variables. ## > ## ----------------- ## > > ACLOCAL='${SHELL} /bioportal/build/EMBOSS-4.0.0/missing --run aclocal-1.9' > AJAX_FIXED_ROOT='\"/bioportal/build/EMBOSS-4.0.0/emboss\"' > AMDEPBACKSLASH='\' > AMDEP_FALSE='#' > AMDEP_TRUE='' > AMPNG_FALSE='#' > AMPNG_TRUE='' > AMTAR='${SHELL} /bioportal/build/EMBOSS-4.0.0/missing --run tar' > AR='ar' > AUTOCONF='${SHELL} /bioportal/build/EMBOSS-4.0.0/missing --run autoconf' > AUTOHEADER='${SHELL} /bioportal/build/EMBOSS-4.0.0/missing --run autoheader' > AUTOMAKE='${SHELL} /bioportal/build/EMBOSS-4.0.0/missing --run automake-1.9' > AWK='gawk' > CC='gcc' > CCDEPMODE='depmode=gcc3' > CFLAGS=' -O2 -D__EXTENSIONS__' > CPP='gcc -E' > CPPFLAGS='-DAJ_SolarisLF -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -DBENDIAN -I/local/include -DNO_AUTH' > CXX='g++' > CXXCPP='g++ -E' > CXXDEPMODE='depmode=gcc3' > CXXFLAGS='-g -O2 ' > CYGPATH_W='echo' > DEFS='-DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"EMBOSS\" -DVERSION=\"4.0.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_DIRENT_H=1 -DSTDC_HEADERS=1 -DHAVE_UNISTD_H=1 -DGETPGRP_VOID=1 -DHAVE_STRFTIME=1 -DHAVE_UNISTD_H=1 -DHAVE_FORK=1 -DHAVE_VFORK=1 -DHAVE_WORKING_VFORK=1 -DHAVE_WORKING_FORK=1 -DHAVE_VPRINTF=1 -DHAVE_DOPRNT=1 -DHAVE_MEMMOVE=1 -DHAVE_LIBM=1 -DPLD_png=1 ' > DEPDIR='.deps' > ECHO='echo' > ECHO_C='' > ECHO_N='-n' > ECHO_T='' > EGREP='grep -E' > EMBOSS_TOP='/bioportal/build/EMBOSS-4.0.0' > EXEEXT='' > F77='g77' > FFLAGS='-g -O2' > HAVE_MEMMOVE='' > HAVE_STRERROR='' > INSTALL_DATA='${INSTALL} -m 644' > INSTALL_PROGRAM='${INSTALL}' > INSTALL_SCRIPT='${INSTALL}' > INSTALL_STRIP_PROGRAM='${SHELL} $(install_sh) -c -s' > ISAIXIA64='' > ISAIXIA64_FALSE='' > ISAIXIA64_TRUE='#' > ISCYGWIN='' > ISCYGWIN_FALSE='' > ISCYGWIN_TRUE='#' > ISSHARED_FALSE='#' > ISSHARED_TRUE='' > JAVA_OK='' > LDFLAGS=' -L/local/lib -L/local/lib -liconv -R/local/lib -R/local/lib' > LIBOBJS='' > LIBS='-lm -lnsl -lsocket -lgd -lpng -lz -lm -liconv' > LIBTOOL='$(SHELL) $(top_builddir)/libtool' > LN_S='ln -s' > LTLIBOBJS='' > MAKEINFO='${SHELL} /bioportal/build/EMBOSS-4.0.0/missing --run makeinfo' > NEEDAJAX='' > NEEDAJAX_FALSE='' > NEEDAJAX_TRUE='#' > OBJEXT='o' > PACKAGE='EMBOSS' > PACKAGE_BUGREPORT='' > PACKAGE_NAME='' > PACKAGE_STRING='' > PACKAGE_TARNAME='' > PACKAGE_VERSION='' > PATH_SEPARATOR=':' > PCRE_DATE='21-May-2003' > PCRE_LIB_VERSION='0:1:0' > PCRE_MAJOR='4' > PCRE_MINOR='3' > PCRE_POSIXLIB_VERSION='0:0:0' > PCRE_VERSION='4.3' > POSIX_MALLOC_THRESHOLD='-DPOSIX_MALLOC_THRESHOLD=10' > PURIFY_FALSE='' > PURIFY_TRUE='#' > RANLIB='ranlib' > SET_MAKE='' > SHELL='/bin/bash' > STRIP='strip' > VERSION='4.0.0' > XLIB=' -L/usr/lib -R/usr/lib -lX11 -lsocket -lnsl' > X_CFLAGS='' > X_EXTRA_LIBS='-lsocket -lnsl' > X_LIBS=' -L/usr/lib -R/usr/lib' > X_PRE_LIBS=' -lSM -lICE' > ac_ct_AR='ar' > ac_ct_CC='gcc' > ac_ct_CXX='g++' > ac_ct_F77='g77' > ac_ct_RANLIB='ranlib' > ac_ct_STRIP='strip' > am__fastdepCC_FALSE='#' > am__fastdepCC_TRUE='' > am__fastdepCXX_FALSE='#' > am__fastdepCXX_TRUE='' > am__include='include' > am__leading_dot='.' > am__quote='' > am__tar='${AMTAR} chof - "$$tardir"' > am__untar='${AMTAR} xf -' > bindir='${exec_prefix}/bin' > build='sparc-sun-solaris2.10' > build_alias='' > build_cpu='sparc' > build_os='solaris2.10' > build_vendor='sun' > datadir='${prefix}/share' > exec_prefix='${prefix}' > havejavac='' > host='sparc-sun-solaris2.10' > host_alias='' > host_cpu='sparc' > host_os='solaris2.10' > host_vendor='sun' > includedir='${prefix}/include' > infodir='${prefix}/info' > install_sh='/bioportal/build/EMBOSS-4.0.0/install-sh' > libdir='${exec_prefix}/lib' > libexecdir='${exec_prefix}/libexec' > localstatedir='${prefix}/var' > mandir='${prefix}/man' > mkdir_p='mkdir -p --' > oldincludedir='/usr/include' > prefix='/bioportal/sw/encap/emboss-4.0.0' > program_transform_name='s,x,x,' > sbindir='${exec_prefix}/sbin' > sharedstatedir='${prefix}/com' > sysconfdir='${prefix}/etc' > target_alias='' > > ## ----------- ## > ## confdefs.h. ## > ## ----------- ## > > #define GETPGRP_VOID 1 > #define HAVE_DIRENT_H 1 > #define HAVE_DLFCN_H 1 > #define HAVE_DOPRNT 1 > #define HAVE_FORK 1 > #define HAVE_INTTYPES_H 1 > #define HAVE_LIBM 1 > #define HAVE_MEMMOVE 1 > #define HAVE_MEMORY_H 1 > #define HAVE_STDINT_H 1 > #define HAVE_STDLIB_H 1 > #define HAVE_STRFTIME 1 > #define HAVE_STRINGS_H 1 > #define HAVE_STRING_H 1 > #define HAVE_SYS_STAT_H 1 > #define HAVE_SYS_TYPES_H 1 > #define HAVE_UNISTD_H 1 > #define HAVE_UNISTD_H 1 > #define HAVE_UNISTD_H 1 > #define HAVE_VFORK 1 > #define HAVE_VPRINTF 1 > #define HAVE_WORKING_FORK 1 > #define HAVE_WORKING_VFORK 1 > #define PACKAGE "EMBOSS" > #define PACKAGE_BUGREPORT "" > #define PACKAGE_NAME "" > #define PACKAGE_STRING "" > #define PACKAGE_TARNAME "" > #define PACKAGE_VERSION "" > #define PLD_png 1 > #define STDC_HEADERS 1 > #define STDC_HEADERS 1 > #define VERSION "4.0.0" > #endif > #ifdef __cplusplus > extern "C" void std::exit (int) throw (); using std::exit; > > configure: exit 0 > From gbottu at ben.vub.ac.be Fri Nov 3 03:43:31 2006 From: gbottu at ben.vub.ac.be (Guy Bottu) Date: Fri, 3 Nov 2006 09:43:31 +0100 Subject: [EMBOSS] Emboss-explorer error - Checked by AntiVir DEMO version - In-Reply-To: <454A1396.3020501@indiana.edu> References: <454A1396.3020501@indiana.edu> Message-ID: <20061103084331.GA16016@bigben.ulb.ac.be> On Thu, Nov 02, 2006 at 10:49:42AM -0500, Sumit Middha wrote: > I have setup emboss-explorer and it works fine for most of the tools. > However, fuzznuc, fuzztran seem to give an error (unknown datatype > pattern). That is because in EMBOSS 4 the ACD file for the "fuzzies" have a new datatype called "pattern" ; also, the option "number of allowed mismatches" is now an attribute of "pattern" rather than a separate ACD parameter. Maybe you can send a message to Luke and ask him to mend this. Note by the way that the new version of the interface wEMBOSS, which can handle all the EMBOSS 4 intricacies, is just out. Guy Bottu, Belgian EMBnet Node From pmr at ebi.ac.uk Fri Nov 3 06:01:42 2006 From: pmr at ebi.ac.uk (Peter Rice) Date: Fri, 03 Nov 2006 11:01:42 +0000 Subject: [EMBOSS] IDs in output In-Reply-To: <716af09c0611020816r3d5c30dg1b1c6f1f4d5fea5d@mail.gmail.com> References: <716af09c0611020816r3d5c30dg1b1c6f1f4d5fea5d@mail.gmail.com> Message-ID: <454B2196.8040905@ebi.ac.uk> Hi Bernd, Bernd Web wrote: > Hi, > > Sometimes I use an EMBOSS command directly on a FastA file. > I wonder if it is possible to select the ID used in the output, esp > for FastA records with an NCBI defline. > >> gi|248166|g|AA21972.1| description... > > in the output of an EMBOSS command becomes: > AA21972.1| > > It would be very easy if the ID could be chosen to be the GI number. > Now the ID used depends on the GI record (sp, pdb, pir) show different > IDs in EMBOSS output. Did you mistype the defline? There is a defined set of database names that can appear in NCBI deflines. If the "|g|" is really "gb" then the ID will be AA21972 which is what I would expect. If the database name is invalid (or a new one unknown to EMBOSS) then we could try to use the GI number. but the "EMBOSS way" would be to use the accession number from the sequence version. Unfortunately at present it is using the last part of sequence version "1" as the ID in your example. I will fix it for the next release. You can use -sid on the command line to give an ID to a sequence that does not have one,but not to replace an existing ID. That seems strange. It may change for the next release so that you can always use -sid to define the ID. Hope that helps Peter From maoj at helix.nih.gov Fri Nov 3 06:55:33 2006 From: maoj at helix.nih.gov (Jean Mao) Date: Fri, 3 Nov 2006 06:55:33 -0500 Subject: [EMBOSS] Emboss-explorer error - Checked by AntiVir DEMOversion - In-Reply-To: <20061103084331.GA16016@bigben.ulb.ac.be> Message-ID: <000b01c6ff3e$f7d36780$be4de780@CIT.NIH.GOV> Is there a temporary solution that I can do to EMBOSS-4.0.0 to fix the datatype errors instead of waiting for solution from Luke? I sent several emails to him but got no response at all for a long while. Thank you very much! Jean -----Original Message----- From: Guy Bottu [mailto:gbottu at ben.vub.ac.be] Sent: 2006?11?3? 3:44 To: Sumit Middha Cc: emboss at emboss.open-bio.org Subject: Re: [EMBOSS] Emboss-explorer error - Checked by AntiVir DEMOversion - On Thu, Nov 02, 2006 at 10:49:42AM -0500, Sumit Middha wrote: > I have setup emboss-explorer and it works fine for most of the tools. > However, fuzznuc, fuzztran seem to give an error (unknown datatype > pattern). That is because in EMBOSS 4 the ACD file for the "fuzzies" have a new datatype called "pattern" ; also, the option "number of allowed mismatches" is now an attribute of "pattern" rather than a separate ACD parameter. Maybe you can send a message to Luke and ask him to mend this. Note by the way that the new version of the interface wEMBOSS, which can handle all the EMBOSS 4 intricacies, is just out. Guy Bottu, Belgian EMBnet Node _______________________________________________ EMBOSS mailing list EMBOSS at lists.open-bio.org http://lists.open-bio.org/mailman/listinfo/emboss From bernd.web at gmail.com Fri Nov 3 07:29:35 2006 From: bernd.web at gmail.com (Bernd Web) Date: Fri, 3 Nov 2006 13:29:35 +0100 Subject: [EMBOSS] IDs in output In-Reply-To: <454B2196.8040905@ebi.ac.uk> References: <716af09c0611020816r3d5c30dg1b1c6f1f4d5fea5d@mail.gmail.com> <454B2196.8040905@ebi.ac.uk> Message-ID: <716af09c0611030429t606b4659wb553f7b8504669d3@mail.gmail.com> Hi Peter, Although I copy pasted, indeed the defline was wrong. It should have been: >gi|248166|gb|AAB21972.1| invertase {EC 3.2.1.26} [baker's yeast, Peptide Partial, 6 aa, segment 10 of 12] ATNTTL EMBOSS extracts "AAB21972.1". Having the version number is OK since otherwise the sequence is not completely defined (AAB21972 could refer to multiple versions). My idea was more related to selecting the GI number as ID to use in EMBOSS applications. Now the accession number depends on the format of the defline: sp -> Entry Name (not primary accession) ref, emb, gb -> Accesion pdb -> PDB protein name with Chain concatenated to it. Although I wrote a script to map the names from NCBI deflines to EMBOSS names, it could be easy to have the option to use the GI number. Regards, Bernd On 11/3/06, Peter Rice wrote: > Hi Bernd, > > Bernd Web wrote: > > Hi, > > > > Sometimes I use an EMBOSS command directly on a FastA file. > > I wonder if it is possible to select the ID used in the output, esp > > for FastA records with an NCBI defline. > > > >> gi|248166|g|AA21972.1| description... > > > > in the output of an EMBOSS command becomes: > > AA21972.1| > > > > It would be very easy if the ID could be chosen to be the GI number. > > Now the ID used depends on the GI record (sp, pdb, pir) show different > > IDs in EMBOSS output. > > Did you mistype the defline? There is a defined set of database names that can > appear in NCBI deflines. If the "|g|" is really "gb" then the ID will be AA21972 > which is what I would expect. > > If the database name is invalid (or a new one unknown to EMBOSS) then we could > try to use the GI number. but the "EMBOSS way" would be to use the accession > number from the sequence version. Unfortunately at present it is using the last > part of sequence version "1" as the ID in your example. I will fix it for the > next release. > > You can use -sid on the command line to give an ID to a sequence that does not > have one,but not to replace an existing ID. That seems strange. It may change > for the next release so that you can always use -sid to define the ID. > > Hope that helps > > Peter > > > > > From praneet at Sun.COM Fri Nov 3 06:59:06 2006 From: praneet at Sun.COM (praneet) Date: Fri, 03 Nov 2006 17:29:06 +0530 Subject: [EMBOSS] Parallelizing Emboss Message-ID: <454B2F0A.3030703@sun.com> Hello Everyone, We at Sun Microsystems just got started with Emboss. So, apologies if you don't find the questions asked below as particularly bright. We are evaluating Emboss and trying to figure out if it can be parallelized. Eventually, Emboss* may be* available on Sun Grid (http://www.sun.com/service/sungrid/overview.jsp and http://www.network.com/). I've a few questions 1. What do you think is the best way to parallelize Emboss? best here means we are ready for a cost performance trade-off. Our options are 1. Input partioning or 2. Writing mpi constructs 2. Are there any existing guidelines/ reference implementation/ docs or any relevant material pertaining to parallelizing Emboss? 3. Out of the 160 applications, which ones do you think should be parallelized? We don't have time to parallelize all applications if we go the mpi route. A starting list of 5 applications would serve our purpose. From what I could find on the net, palindrome and einverted seem to be slow. Are these two good candidates to get us started? Anything else that you think may enlighten us would be heartily welcome. Thanks in advance --praneet From pmr at ebi.ac.uk Fri Nov 3 08:31:40 2006 From: pmr at ebi.ac.uk (Peter Rice) Date: Fri, 03 Nov 2006 13:31:40 +0000 Subject: [EMBOSS] IDs in output In-Reply-To: <716af09c0611030429t606b4659wb553f7b8504669d3@mail.gmail.com> References: <716af09c0611020816r3d5c30dg1b1c6f1f4d5fea5d@mail.gmail.com> <454B2196.8040905@ebi.ac.uk> <716af09c0611030429t606b4659wb553f7b8504669d3@mail.gmail.com> Message-ID: <454B44BC.2000001@ebi.ac.uk> Bernd Web wrote: > Hi Peter, > > Although I copy pasted, indeed the defline was wrong. It should have been: > >> gi|248166|gb|AAB21972.1| invertase {EC 3.2.1.26} [baker's yeast, > Peptide Partial, 6 aa, segment 10 of 12] > ATNTTL > > EMBOSS extracts "AAB21972.1". > Having the version number is OK since otherwise the sequence is not > completely defined (AAB21972 could refer to multiple versions). If you specify -osformat ncbi you should be able to recreate the original defline in the EMBOSS output. > My idea was more related to selecting the GI number as ID to use in > EMBOSS applications. Now the accession number depends on the format of > the defline: > sp -> Entry Name (not primary accession) If there is an Entry name EMBOSS will use it. > ref, emb, gb -> Accesion But now EMBL and Genbank define this as the entry name anyway. > pdb -> PDB protein name with Chain concatenated to it. That seems good to me ... although we know of a problem when there are more than 26 chains and -a comes round again. > Although I wrote a script to map the names from NCBI deflines to > EMBOSS names, it could be easy to have the option to use the GI > number. Hmmm ..... in EMBOSS terms, this counts as yet another sequence format. We could make a new output format (-osformat gifasta for example) that uses the GI as the ID... but it would use the original sequence name as the filename first time around (and then when you read the file it would start using the GI number as the filename). But we could also make "gifasta" an input format (-sformat gifasta) and then it could use the GI number - but you would have to specify the -sformat on the command line (or gifasta::filename as input) because EMBOSS has to choose which way to interpret the defline. Does that solve your problem? NCBI regard the ID as the entire string with "|" characters embedded, but that is no use when making filenames so we had to choose something. EMBL does not use GI numbers ... they only appear in GenBank and NCBI files. I never liked them, but EMBOSS does try to do whatever the users demand :-) regards, Peter From paul.guermonprez at intel.com Fri Nov 3 08:55:41 2006 From: paul.guermonprez at intel.com (Guermonprez, Paul) Date: Fri, 3 Nov 2006 13:55:41 -0000 Subject: [EMBOSS] Parallelizing Emboss Message-ID: <48F17FCD4E8AB449BD956AF127AE4FD4E9FA85@IRSMSX411> hello, Glad to hear it, a good target may be "water", a smith waterman implementation. We had a similar topic on [emboss-dev] lately. Of course before parallelizing an algo the first step is to optimize it in serial mode, you may find information about emboss-water optimization done at intel a few months ago here : please find the pdf of the slides here : http://www.guermonprez.net/projects/emboss/emboss-EBI_06_06.pdf and the sources here (need emboss 3.0.0 to work) : http://www.guermonprez.net/projects/emboss/emboss-runsh.tar.gz the software speed gain ( x11 ) was measured on intel architecture but you can get more or less the same on different hardware too. regards, paul. Paul Guermonprez - Intel Sr. Software Engineer - Digital Health EMEA email : paul.guermonprez at intel.com phone : +33 1 58 87 72 41 mobile : +33 6 26 23 67 62 -----Original Message----- From: emboss-bounces at lists.open-bio.org [mailto:emboss-bounces at lists.open-bio.org] On Behalf Of praneet Sent: Friday, November 03, 2006 12:59 PM To: emboss at lists.open-bio.org Subject: [EMBOSS] Parallelizing Emboss Hello Everyone, We at Sun Microsystems just got started with Emboss. So, apologies if you don't find the questions asked below as particularly bright. We are evaluating Emboss and trying to figure out if it can be parallelized. Eventually, Emboss* may be* available on Sun Grid (http://www.sun.com/service/sungrid/overview.jsp and http://www.network.com/). I've a few questions 1. What do you think is the best way to parallelize Emboss? best here means we are ready for a cost performance trade-off. Our options are 1. Input partioning or 2. Writing mpi constructs 2. Are there any existing guidelines/ reference implementation/ docs or any relevant material pertaining to parallelizing Emboss? 3. Out of the 160 applications, which ones do you think should be parallelized? We don't have time to parallelize all applications if we go the mpi route. A starting list of 5 applications would serve our purpose. From what I could find on the net, palindrome and einverted seem to be slow. Are these two good candidates to get us started? Anything else that you think may enlighten us would be heartily welcome. Thanks in advance --praneet _______________________________________________ EMBOSS mailing list EMBOSS at lists.open-bio.org http://lists.open-bio.org/mailman/listinfo/emboss From msarachu at biol.unlp.edu.ar Fri Nov 3 10:41:26 2006 From: msarachu at biol.unlp.edu.ar (=?ISO-8859-1?Q?Mart=EDn_Sarachu?=) Date: Fri, 03 Nov 2006 12:41:26 -0300 Subject: [EMBOSS] wrappers4EMBOSS-1.5.1 released Message-ID: <454B6326.1000907@biol.unlp.edu.ar> This release adds some extra toggle buttons for muscle, phiblast and psiblast to comply to wEMBOSS not allowing users to choose name for output files. These programs needs to create extra files and thus the toggle buttons allow it under wEMBOSS. wrappers4EMBOSS can de downloaded from http://www.wemboss.org Best regards, The wrappers4EMBOSS team From gbottu at ben.vub.ac.be Sun Nov 5 14:15:56 2006 From: gbottu at ben.vub.ac.be (Guy Bottu) Date: Sun, 5 Nov 2006 20:15:56 +0100 Subject: [EMBOSS] using emboss programs from spin] - Checked by AntiVir DEMO version In-Reply-To: <4549A594.4050205@yahoo.es> References: <4549A594.4050205@yahoo.es> Message-ID: <20061105191556.GA21963@bigben.ulb.ac.be> On Thu, Nov 02, 2006 at 09:00:20AM +0100, Miguel Ortiz Lombardia wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Here, a number of users are quite afraid of the command line ;-{ so they > would appreciate a graphic interface to EMBOSS. We tried Jemboss first, > but got a number of problems that we couldn't solve (essentially with > some results text files being corrupted). Then, I met with this > interface from the Staden package, and found it very useful, to a > certain extent. Dear Miguel, If you want a GUI for EMBOSS another possibility is wEMBOSS, a Web interface with the user data permanently stored at the side of the server. A version that fully supports EMBOSS 4 is just out (see http://wemboss.sourceforge.net). However, I consider that Staden spin remains useful. When I personally have to do some bioinformatic analysis with EMBOSS, I usually work at the command line. But for programs that produce an XY-graph I use spin, because it has this nice feature of displaying in one window a zoomable graph and in another window the sequence, allowing to see which detail of the graph corresponds to which range of the sequence. Regards, Guy Bottu, BEN From golharam at umdnj.edu Mon Nov 6 22:57:56 2006 From: golharam at umdnj.edu (Ryan Golhar) Date: Mon, 06 Nov 2006 22:57:56 -0500 Subject: [EMBOSS] using emboss programs from spin] - Checked by AntiVirDEMO version In-Reply-To: <20061105191556.GA21963@bigben.ulb.ac.be> Message-ID: <002a01c70220$e92036c0$2f01a8c0@GOLHARMOBILE1> Take a look at the web site, http://emboss.sourceforge.net. There are a number of web interfaces available. They all have different strengths/weaknesses, so decide upon what it is you are looking for - that should help you choose one. > -----Original Message----- > From: emboss-bounces at lists.open-bio.org > [mailto:emboss-bounces at lists.open-bio.org] On Behalf Of Guy Bottu > Sent: Sunday, November 05, 2006 2:16 PM > To: Miguel Ortiz Lombardia > Cc: emboss at emboss.open-bio.org > Subject: Re: [EMBOSS] using emboss programs from spin] - > Checked by AntiVirDEMO version > > > On Thu, Nov 02, 2006 at 09:00:20AM +0100, Miguel Ortiz > Lombardia wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Here, a number of users are quite afraid of the command line ;-{ so > > they would appreciate a graphic interface to EMBOSS. We > tried Jemboss > > first, but got a number of problems that we couldn't solve > > (essentially with some results text files being corrupted). Then, I > > met with this interface from the Staden package, and found it very > > useful, to a certain extent. > > Dear Miguel, > > If you want a GUI for EMBOSS another possibility is wEMBOSS, > a Web interface with > the user data permanently stored at the side of the server. A > version that fully > supports EMBOSS 4 is just out (see http://wemboss.sourceforge.net). > > However, I consider that Staden spin remains useful. When I > personally have to do > some bioinformatic analysis with EMBOSS, I usually work at > the command line. But for > programs that produce an XY-graph I use spin, because it has > this nice feature of > displaying in one window a zoomable graph and in another > window the sequence, > allowing to see which detail of the graph corresponds to > which range of the > sequence. > > Regards, > Guy Bottu, > BEN > > _______________________________________________ > EMBOSS mailing list > EMBOSS at lists.open-bio.org > http://lists.open-> bio.org/mailman/listinfo/emboss > From ajb at ebi.ac.uk Wed Nov 8 09:18:05 2006 From: ajb at ebi.ac.uk (ajb at ebi.ac.uk) Date: Wed, 8 Nov 2006 14:18:05 -0000 (GMT) Subject: [EMBOSS] Jemboss patch on the EMBOSS ftp server Message-ID: <54309.81.98.244.247.1162995485.squirrel@webmail.ebi.ac.uk> There is now a fix for Jemboss on the EMBOSS ftp server. This fixes a problem involving the specification of mismatches in "the fuzzies" (i.e. fuzznuc etc). See the ftp://emboss.open-bio.org/pub/EMBOSS/fixes/README.fixes or the ftp://emboss.open-bio.org/pub/EMBOSS/fixes/patches/README.patch files to find out how to apply the fix. The patch-1-19.gz file in the patches directory will, of course, apply all fixes to date when used with a fresh download of EMBOSS-4.0.0.tar.gz. Alan From ajb at ebi.ac.uk Wed Nov 8 10:29:18 2006 From: ajb at ebi.ac.uk (ajb at ebi.ac.uk) Date: Wed, 8 Nov 2006 15:29:18 -0000 (GMT) Subject: [EMBOSS] email list problems fixed Message-ID: <40673.81.98.244.247.1162999758.squirrel@webmail.ebi.ac.uk> You may have experienced problems emailing the EMBOSS lists over the last couple of days. We understand that the problem has now been fixed. Thanks to the Open-Bio team for their usual prompt response. Alan From golharam at umdnj.edu Wed Nov 8 15:15:36 2006 From: golharam at umdnj.edu (Ryan Golhar) Date: Wed, 08 Nov 2006 15:15:36 -0500 Subject: [EMBOSS] Jemboss patch on the EMBOSS ftp server In-Reply-To: <54309.81.98.244.247.1162995485.squirrel@webmail.ebi.ac.uk> Message-ID: <00df01c70372$aaefdd30$2f01a8c0@GOLHARMOBILE1> Hi Alan, I downloaded and applied the patch file. Building EMBOSS fails. I looked into it more and it looks like there are some new additional files in jemboss, specifically in org/emboss/jemboss/gui/form. The patch file only mentioned that the file is new but it doesn't contain the contents of the file. Are the new files in the EMBOSS-4.0.0.tar.gz file or just available from the jemboss-08112006.jar file? Ryan > -----Original Message----- > From: emboss-bounces at lists.open-bio.org > [mailto:emboss-bounces at lists.open-bio.org] On Behalf Of ajb at ebi.ac.uk > Sent: Wednesday, November 08, 2006 9:18 AM > To: emboss at emboss.open-bio.org > Subject: [EMBOSS] Jemboss patch on the EMBOSS ftp server > > > There is now a fix for Jemboss on the EMBOSS ftp server. This > fixes a problem involving the specification of mismatches in > "the fuzzies" (i.e. fuzznuc etc). > > See the > ftp://emboss.open-> bio.org/pub/EMBOSS/fixes/README.fixes or > the > ftp://emboss.open-bio.org/pub/EMBOSS/fixes/patches/README.patch files to find out how to apply the fix. The patch-1-19.gz file in the patches directory will, of course, apply all fixes to date when used with a fresh download of EMBOSS-4.0.0.tar.gz. Alan _______________________________________________ EMBOSS mailing list EMBOSS at lists.open-bio.org http://lists.open-bio.org/mailman/listinfo/emboss From ajb at ebi.ac.uk Wed Nov 8 16:41:06 2006 From: ajb at ebi.ac.uk (ajb at ebi.ac.uk) Date: Wed, 8 Nov 2006 21:41:06 -0000 (GMT) Subject: [EMBOSS] Jemboss patch on the EMBOSS ftp server In-Reply-To: <00df01c70372$aaefdd30$2f01a8c0@GOLHARMOBILE1> References: <54309.81.98.244.247.1162995485.squirrel@webmail.ebi.ac.uk> <00df01c70372$aaefdd30$2f01a8c0@GOLHARMOBILE1> Message-ID: <35979.81.98.244.247.1163022066.squirrel@webmail.ebi.ac.uk> Hi Ryan, Thanks for pointing out the error. I've put a replacement patch-1-19.gz on the ftp server. Let me know if you still have a problem. Alan From golharam at umdnj.edu Thu Nov 9 00:54:22 2006 From: golharam at umdnj.edu (Ryan Golhar) Date: Thu, 09 Nov 2006 00:54:22 -0500 Subject: [EMBOSS] EMBOSS RPMs Message-ID: <00fa01c703c3$81b72d00$2f01a8c0@GOLHARMOBILE1> In case anyone is interested, I've rebuilt the EMBOSS RPMs to include the latest patch. They are available from the EMBOSS download page, or from http://informatics.umdnj.edu/BioRPMs Ryan From roberto.pava at gmail.com Thu Nov 9 10:53:50 2006 From: roberto.pava at gmail.com (Roberto Pava) Date: Thu, 9 Nov 2006 10:53:50 -0500 Subject: [EMBOSS] Help with equicktandem and etandem Message-ID: <1816142e0611090753g3e58215bh6982f5af78676413@mail.gmail.com> Hello, I'm a revision of methods to find repeats on biological sequences. I can't understand the algorithm of equicktandem and etandem. Please, somebody can send to me a description of algorithms or link where I cant find it. Thanks Roberto A. Pava http://roberto.pava.googlepages.com From gbottu at ben.vub.ac.be Thu Nov 9 14:00:07 2006 From: gbottu at ben.vub.ac.be (Guy Bottu) Date: Thu, 9 Nov 2006 20:00:07 +0100 Subject: [EMBOSS] about restriction mapping - Checked by AntiVir DEMO version - Message-ID: <20061109190007.GB106@bigben.ulb.ac.be> Dear EMBOSS team, While giving a course yesterday I was reminded of the following thing : Under GCG the restriction mapping programs have a parameter allowing to precise sequence ranges where enzymes are not allowed to cut. This can be very useful, e.g. when you want to select restriction enzymes that allow to cut out a gene to be cloned (which of course should not cut inside the gene). Would it not be nice if the EMBOSS programs had the same functionality ? Does anybody else also feel a need for this feature ? Guy Bottu, BEN From David.Lapointe at umassmed.edu Thu Nov 9 15:13:37 2006 From: David.Lapointe at umassmed.edu (Lapointe, David) Date: Thu, 9 Nov 2006 15:13:37 -0500 Subject: [EMBOSS] Adding Codon Tables Message-ID: <7D402AC3CCB55742BEBBA6C3031C29083A6B69@edunivmail01.ad.umassmed.edu> I created a new codon table (EGC.24) and added an entry to the end of EGC.index, but transeq does not accept table values outside of 0..23. What is the procedure for adding a new codon table? David David Lapointe, Ph.D. Manager - Research Computing UMass Medical School Worcester MA 01655 508-856-7600 From pmr at ebi.ac.uk Thu Nov 9 18:26:11 2006 From: pmr at ebi.ac.uk (pmr at ebi.ac.uk) Date: Thu, 9 Nov 2006 23:26:11 -0000 (GMT) Subject: [EMBOSS] Adding Codon Tables In-Reply-To: <7D402AC3CCB55742BEBBA6C3031C29083A6B69@edunivmail01.ad.umassmed.edu> References: <7D402AC3CCB55742BEBBA6C3031C29083A6B69@edunivmail01.ad.umassmed.edu> Message-ID: <1403.86.132.218.102.1163114771.squirrel@webmail.ebi.ac.uk> Dear David, > I created a new codon table (EGC.24) and added an entry to the end of > EGC.index, but transeq > does not accept table values outside of 0..23. > > What is the procedure for adding a new codon table? The transeq.acd file has a list of known genetic codes. We have the capability to automate the list, but it is a little tricky for those who write ACD parsers. As nobody has complained in version 4.0.0 we will automate it to use the EGC.index file for all applications in a future release. regards, Peter From pmr at ebi.ac.uk Thu Nov 9 18:30:07 2006 From: pmr at ebi.ac.uk (pmr at ebi.ac.uk) Date: Thu, 9 Nov 2006 23:30:07 -0000 (GMT) Subject: [EMBOSS] about restriction mapping - Checked by AntiVir DEMO version - In-Reply-To: <20061109190007.GB106@bigben.ulb.ac.be> References: <20061109190007.GB106@bigben.ulb.ac.be> Message-ID: <1414.86.132.218.102.1163115007.squirrel@webmail.ebi.ac.uk> Dear Guy, > While giving a course yesterday I was reminded of the following thing : > Under GCG the restriction mapping programs have a parameter allowing to > precise sequence ranges where enzymes are not allowed to cut. This can be > very useful, e.g. when you want to select restriction enzymes that allow > to cut out a gene to be cloned (which of course should not cut inside the > gene). Would it not be nice if the EMBOSS programs had the same > functionality ? Does anybody else also feel a need for this feature ? Easy to add as a set of ranges with a new qualifier. All we need is to know how many users want us to do it. regards, Peter From pmr at ebi.ac.uk Thu Nov 9 18:47:15 2006 From: pmr at ebi.ac.uk (pmr at ebi.ac.uk) Date: Thu, 9 Nov 2006 23:47:15 -0000 (GMT) Subject: [EMBOSS] Help with equicktandem and etandem In-Reply-To: <1816142e0611090753g3e58215bh6982f5af78676413@mail.gmail.com> References: <1816142e0611090753g3e58215bh6982f5af78676413@mail.gmail.com> Message-ID: <1557.86.132.218.102.1163116035.squirrel@webmail.ebi.ac.uk> Hi Roberto, > Hello, I'm a revision of methods to find repeats on biological > sequences. I can't understand the algorithm of equicktandem and > etandem. > > Please, somebody can send to me a description of algorithms or link > where I can find it. These programs were written by Richard Durbin at the Sanger Institute. Unfortunately there was never any documentation of the algorithms so we have to try to understand them by reading the source code. I will have another try at interpreting what is happening and update the documentation. Do you have any specific questions about how they work? regards, Peter Rice From henrikki.almusa at medicel.com Fri Nov 10 03:50:28 2006 From: henrikki.almusa at medicel.com (Henrikki Almusa) Date: Fri, 10 Nov 2006 10:50:28 +0200 Subject: [EMBOSS] Adding Codon Tables In-Reply-To: <1403.86.132.218.102.1163114771.squirrel@webmail.ebi.ac.uk> References: <7D402AC3CCB55742BEBBA6C3031C29083A6B69@edunivmail01.ad.umassmed.edu> <1403.86.132.218.102.1163114771.squirrel@webmail.ebi.ac.uk> Message-ID: <45543D54.3090309@medicel.com> pmr at ebi.ac.uk wrote: >> I created a new codon table (EGC.24) and added an entry to the end of >> EGC.index, but transeq >> does not accept table values outside of 0..23. >> >> What is the procedure for adding a new codon table? > > The transeq.acd file has a list of known genetic codes. > > We have the capability to automate the list, but it is a little tricky for > those who write ACD parsers. As nobody has complained in version 4.0.0 we > will automate it to use the EGC.index file for all applications in a > future release. By the way. I hope that the added codon files get new numbers in the ACD files? Mainly as if people have scripts (or other automated workflows) the meaning the numbers should not change later on. Same of course is a concern for any automation that is added if it has an effect on the user interfaces. Regards, -- Henrikki Almusa Medicel Oy Phone: +358 9 386 7092 http://www.medicel.com From golharam at umdnj.edu Fri Nov 10 23:49:32 2006 From: golharam at umdnj.edu (Ryan Golhar) Date: Fri, 10 Nov 2006 23:49:32 -0500 Subject: [EMBOSS] Emboss-explorer error - Checked by AntiVir DEMOversion - In-Reply-To: <000b01c6ff3e$f7d36780$be4de780@CIT.NIH.GOV> Message-ID: <000501c7054c$c97240f0$2f01a8c0@GOLHARMOBILE1> > -----Original Message----- > From: emboss-bounces at lists.open-bio.org > [mailto:emboss-bounces at lists.open-bio.org] On Behalf Of Jean Mao > Sent: Friday, November 03, 2006 6:56 AM > To: 'Guy Bottu'; Sumit Middha > Cc: emboss at emboss.open-bio.org > Subject: Re: [EMBOSS] Emboss-explorer error - Checked by > AntiVir DEMOversion - > > > Is there a temporary solution that I can do to EMBOSS-4.0.0 > to fix the datatype errors instead of waiting for solution > from Luke? I sent several emails to him but got no response > at all for a long while. Thank you very much! > > Jean I have a fix to this: In the XHTML.pm file, located in /usr/lib/perl5/site_perl/5.8.0/EMBOSS/GUI, you can apply this patch: ---BEGIN--- --- XHTML.pm 2006-11-10 23:38:31.000000000 -0500 +++ /usr/lib/perl5/site_perl/5.8.0/EMBOSS/GUI/XHTML.pm 2006-11-10 23:41:34.000000000 -0500 @@ -955,6 +955,10 @@ &_acd_infile; } +sub _acd_pattern { + &_text_field_html; +} + sub _acd_sequence { my ($self, $param) = @_; ---END--- Basically, add the function _acd_pattern to XHTML.pm. I can email you a fresh copy of XHTML.pm if you would like instead of applying a patch. I'll post this fix up on sourceforge as well. Ryan From mthon at tamu.edu Sun Nov 12 07:27:20 2006 From: mthon at tamu.edu (Michael Thon) Date: Sun, 12 Nov 2006 06:27:20 -0600 Subject: [EMBOSS] tranalign errors Message-ID: <9229557C-0B64-45B1-81CC-B7545B9F5403@tamu.edu> Hello - I'm trying to use tranalign to align DNA sequences but it keeps throwing errors. I tested it on the example input files from the documentation web pages and those work fine. here's an example session with the errors: tranalign fasta::stm1likedna.fasta fasta::stm1_prot_aln.fasta Align nucleic coding regions given the aligned proteins nucleotide output sequence set [ss1g01814.fasta]: Error: Guide protein sequence SS1G01814 not found in nucleic sequence SS1G01814 it throws the same error for every pair of proteins in the file here are the sequence names in the files. I can supply the full files if anyone thinks they can help. thanks in advance... Mike [mike at mikes-laptop phylo]$ grep '>' stm1likedna.fasta >SS1G01814 >SS1G03605 >SS1G07709 >SS1G11564 >BC1G02874 >BC1G08371 >BC1G15724 [mike at mikes-laptop phylo]$ grep '>' stm1_prot_aln.fasta >SS1G01814 >SS1G03605 >SS1G07709 >SS1G11564 >BC1G02874 >BC1G08371 >BC1G15724 From pmr at ebi.ac.uk Sun Nov 12 12:11:00 2006 From: pmr at ebi.ac.uk (pmr at ebi.ac.uk) Date: Sun, 12 Nov 2006 17:11:00 -0000 (GMT) Subject: [EMBOSS] tranalign errors In-Reply-To: <9229557C-0B64-45B1-81CC-B7545B9F5403@tamu.edu> References: <9229557C-0B64-45B1-81CC-B7545B9F5403@tamu.edu> Message-ID: <2564.86.132.218.102.1163351460.squirrel@webmail.ebi.ac.uk> > Hello - I'm trying to use tranalign to align DNA sequences but it > keeps throwing errors. I tested it on the example input files from > the documentation web pages and those work fine. > > Error: Guide protein sequence SS1G01814 not found in nucleic sequence > SS1G01814 > > it throws the same error for every pair of proteins in the file > > here are the sequence names in the files. I can supply the full > files if anyone thinks they can help. Yes, please send the full files to emboss-bug at emboss.open-bio.org The message is not an ID mismatch - it says the protein sequence did not match the DNA sequence. regards, Peter Rice From mccarthy at users.sourceforge.net Sun Nov 12 21:36:06 2006 From: mccarthy at users.sourceforge.net (Luke McCarthy) Date: Sun, 12 Nov 2006 20:36:06 -0600 Subject: [EMBOSS] EMBOSS explorer 2.2.0 Message-ID: <4557DA16.8000909@users.sourceforge.net> Hi all, EMBOSS explorer 2.2.0 has just been released, after a long delay. It has been updated to work with EMBOSS 4.0.0 (though it should continue to work with EMBOSS 3) Visit http://embossgui.sourceforge.net for more information or to download. Please report any problems using the bug tracker (available from the website above), or by email to mccarthy at users.sourceforge.net. Cheers, Luke From smiddha at indiana.edu Tue Nov 14 00:59:08 2006 From: smiddha at indiana.edu (Sumit) Date: Tue, 14 Nov 2006 00:59:08 -0500 Subject: [EMBOSS] Emboss-explorer error - Checked by AntiVir DEMOversion - In-Reply-To: <000501c7054c$c97240f0$2f01a8c0@GOLHARMOBILE1> References: <000501c7054c$c97240f0$2f01a8c0@GOLHARMOBILE1> Message-ID: <45595B2C.5070703@indiana.edu> Thanks Ryan and others. The new emboss-explorer takes care of this. Sumit Ryan Golhar wrote: >>-----Original Message----- >>From: emboss-bounces at lists.open-bio.org >>[mailto:emboss-bounces at lists.open-bio.org] On Behalf Of Jean Mao >>Sent: Friday, November 03, 2006 6:56 AM >>To: 'Guy Bottu'; Sumit Middha >>Cc: emboss at emboss.open-bio.org >>Subject: Re: [EMBOSS] Emboss-explorer error - Checked by >>AntiVir DEMOversion - >> >> >>Is there a temporary solution that I can do to EMBOSS-4.0.0 >>to fix the datatype errors instead of waiting for solution >>from Luke? I sent several emails to him but got no response >>at all for a long while. Thank you very much! >> >>Jean >> >> > > >I have a fix to this: > >In the XHTML.pm file, located in >/usr/lib/perl5/site_perl/5.8.0/EMBOSS/GUI, you can apply this patch: > >---BEGIN--- >--- XHTML.pm 2006-11-10 23:38:31.000000000 -0500 >+++ /usr/lib/perl5/site_perl/5.8.0/EMBOSS/GUI/XHTML.pm 2006-11-10 >23:41:34.000000000 -0500 >@@ -955,6 +955,10 @@ > &_acd_infile; > } > >+sub _acd_pattern { >+ &_text_field_html; >+} >+ > sub _acd_sequence { > my ($self, $param) = @_; >---END--- > >Basically, add the function _acd_pattern to XHTML.pm. I can email you a >fresh copy of XHTML.pm if you would like instead of applying a patch. >I'll post this fix up on sourceforge as well. > >Ryan > > > > From david.guzman at uniklinik-freiburg.de Mon Nov 20 09:31:43 2006 From: david.guzman at uniklinik-freiburg.de (David Guzman) Date: Mon, 20 Nov 2006 15:31:43 +0100 Subject: [EMBOSS] seqret/entret problems using acc from ensembl-embl Message-ID: <4561BC4F.5010904@uniklinik-freiburg.de> Dear all, I am experiencing a very strange problem using seqret and entret. I have downloaded and indexed with dbiflat the database files from the Homo sapiens subsection of Ensembl (latest version as of Nov 15th). When I try to get one sequence with seqret or the complete entry with entret using the AC code I got the following error message: claudia at pc-31-18-86-200:~> seqret embldnahs:chromosome:NCBI36:1:1000001:1970768:1 Reads and writes (returns) sequences Error: Unable to read sequence 'embldnahs:chromosome:NCBI36:1:1000001:1970768:1' Died: seqret terminated: Bad value for '-sequence' and no prompt I think that the format used by Ensembl for assigning IDs and ACCs is causing the problems. For example the first entry from the flat file: claudia at pc-31-18-86-200:~> head /local/bioinfo/db/ensembl/embl/Homo_sapiens.0.dat ID 1 standard; DNA; HTG; 970768 BP. XX AC chromosome:NCBI36:1:1000001:1970768:1 XX SV chromosome:NCBI36:1:1000001:1970768:1 XX DT 5-OCT-2006 XX DE Homo sapiens chromosome 1 NCBI36 partial sequence 1000001..1970768 DE annotated by Ensembl I tried replacing the ":" character of the AC line with a "_" using sed but after indexing and I get the same error message with seqret or entret. Is there any length limit for IDs or ACCs in EMBOSS? Is there any workaround for this problem? Thanks System: EMBOSS 4.0.0 SUSE 9.3 showdb: # Name Type ID Qry All Comment # ============ ==== == === === ======= embldnahs N OK OK OK Ensembl EMBL DNA H.sapiens emboss.default DB embldnahs [ type: N dir: /local/bioinfo/db/ensembl/embl method: emblcd format: embl file: *.dat comment: "Ensembl EMBL DNA H.sapiens"] -------------- next part -------------- A non-text attachment was scrubbed... Name: david.guzman.vcf Type: text/x-vcard Size: 290 bytes Desc: not available Url : http://lists.open-bio.org/pipermail/emboss/attachments/20061120/47582320/attachment.vcf From pmr at ebi.ac.uk Mon Nov 20 10:52:31 2006 From: pmr at ebi.ac.uk (Peter Rice) Date: Mon, 20 Nov 2006 15:52:31 +0000 Subject: [EMBOSS] seqret/entret problems using acc from ensembl-embl In-Reply-To: <4561BC4F.5010904@uniklinik-freiburg.de> References: <4561BC4F.5010904@uniklinik-freiburg.de> Message-ID: <4561CF3F.4080802@ebi.ac.uk> Hi David, > I think that the format used by Ensembl for assigning IDs and ACCs is > causing the problems. For example the first entry from the flat file: > > claudia at pc-31-18-86-200:~> head > /local/bioinfo/db/ensembl/embl/Homo_sapiens.0.dat > ID 1 standard; DNA; HTG; 970768 BP. > XX > AC chromosome:NCBI36:1:1000001:1970768:1 > XX > SV chromosome:NCBI36:1:1000001:1970768:1 > XX > DT 5-OCT-2006 > XX > DE Homo sapiens chromosome 1 NCBI36 partial sequence 1000001..1970768 > DE annotated by Ensembl > > I tried replacing the ":" character of the AC line with a "_" using sed > but after indexing and I get the same error message with seqret or > entret. Is there any length limit for IDs or ACCs in EMBOSS? Is there > any workaround for this problem? Those IDs are horrible and not really EMBL format... certainly not valid accession numbers. We will add an ENSEMBL format for the next release... as a sequence format and as a format for dbiflat and the (preferred) dbxflat. Hope that helps, Peter From golergka at gmail.com Thu Nov 23 01:29:15 2006 From: golergka at gmail.com (Maxim Jankov) Date: Thu, 23 Nov 2006 09:29:15 +0300 Subject: [EMBOSS] Simple configuration of databases Message-ID: <940db11d0611222229m75313353m5bc0e357dffe37d9@mail.gmail.com> Hi, dear all :) I'm quite new to emboss and never been to serious administration routine, but now I need to have a proper installation of emboss at home (Ubuntu 6.10) for educational purposes (cos university server goes down often) - and not only emboss, but all the main databases, like swissprot, embl, pdb and for sure several more that I yet dunno about. Fortunately, I don't want to download all these gigabytes, and better configure emboss to work with all that db's online. But the bad thing is that I'm completely stuck in all that manuals and just begging for help of someone who done configuration like that and can provide me with ready or easy-to-understand config files. Thank you. From jerome at ibt.unam.mx Thu Nov 23 13:43:30 2006 From: jerome at ibt.unam.mx (Jerome) Date: Thu, 23 Nov 2006 12:43:30 -0600 Subject: [EMBOSS] How to indexing a bactria genome ? Message-ID: <4565EBD2.6040204@ibt.unam.mx> Hi all, I'm trying to use the flat file of a genome of a bacteria. As i can read in this file (U00096_GR.dat), i've get all the information about CDS, proteins and a lot more. For example, there is a information about "aspartate kinase activity".. And i would like to indexing this information as "Description" in my emboss database. But when i do the indexing, the result is just on sequence, the all geneme nuclear acid. I don't know if dbiflat permits what i want to do, or i would use another type of flat file?. Thank's. Best Regards. -- -- J?r?me Maman ach?te souvent des cravates pour papa, mais papa ne les met presque jamais. Elles sont si belles qu'il doit avoir peur de les salir. (Histoires in?dites du Petit Nicolas, Goscinny & Semp?) From gbottu at ben.vub.ac.be Thu Nov 23 14:02:45 2006 From: gbottu at ben.vub.ac.be (Guy Bottu) Date: Thu, 23 Nov 2006 20:02:45 +0100 Subject: [EMBOSS] Simple configuration of databases - Checked by AntiVir DEM In-Reply-To: <940db11d0611222229m75313353m5bc0e357dffe37d9@mail.gmail.com> References: <940db11d0611222229m75313353m5bc0e357dffe37d9@mail.gmail.com> Message-ID: <20061123190245.GB32105@bigben.ulb.ac.be> On Thu, Nov 23, 2006 at 09:29:15AM +0300, Maxim Jankov wrote: > Fortunately, I don't want to download all these gigabytes, and better > configure emboss to work with all that db's online. But the bad thing is > that I'm completely stuck in all that manuals and just begging for help of > someone who done configuration like that and can provide me with ready or > easy-to-understand config files. Dear Maxim, I can provide you just like that with some remote databank definitions we use at the BEN site. Put in your file .../share/EMBOSS/emboss.default : DB NCBI_NUC [ type: N method: entrez format: genbank comment: 'nonredundant nuc. acid db at NCBI (by GI number)' ] DB NCBI_PROT [ type: P method: entrez format: genbank comment: 'nonredundant protein db at NCBI (by GI number)' ] DB EBI_EMBL [ type: N methodquery: external format: embl comment: 'EMBL at EBI' app: '/opt/sw/EBIWS/WSDbfetchClient.pl fetchData embl:%s' ] DB EBI_EMBLSVA [ type: N methodquery: external format: embl comment: 'EMBL Sequence Version Archive at EBI (by SV)' app: '/opt/sw/EBIWS/WSDbfetchClient.pl fetchData emblsva:%s' ] DB EBI_EMBLCDS [ type: N methodquery: external format: embl comment: 'EMBL Coding Sequences at EBI (by ProteinID)' app: '/opt/sw/EBIWS/WSDbfetchClient.pl fetchData emblcds:%s' ] Note : EMBOSS does have a databank access method "dbfetch", but I never managed to get it working (can someone who did tell me how ?). Instead I use the script WSDbfetchClient.pl (see attachment). To make it work you will need to install in your Perl the module SOAP-Lite (version 0.60 and not higher !). You will have to adapt the "app" parameter here above and the "shebang line" of the script. Regards, Guy Bottu, Belgian EMBnet Node -------------- next part -------------- A non-text attachment was scrubbed... Name: WSDbfetchClient.pl Type: application/x-perl Size: 3103 bytes Desc: not available Url : http://lists.open-bio.org/pipermail/emboss/attachments/20061123/df51a552/attachment-0001.bin From pmr at ebi.ac.uk Thu Nov 23 18:58:22 2006 From: pmr at ebi.ac.uk (pmr at ebi.ac.uk) Date: Thu, 23 Nov 2006 23:58:22 -0000 (GMT) Subject: [EMBOSS] How to indexing a bactria genome ? In-Reply-To: <4565EBD2.6040204@ibt.unam.mx> References: <4565EBD2.6040204@ibt.unam.mx> Message-ID: <2613.81.178.231.206.1164326302.squirrel@webmail.ebi.ac.uk> Hi Jerome, > I'm trying to use the flat file of a genome of a bacteria. > As i can read in this file (U00096_GR.dat), i've get all the information > about CDS, proteins and a lot more. For example, there is a information > about "aspartate kinase activity".. And i would like to indexing this > information as "Description" in my emboss database. > > But when i do the indexing, the result is just on sequence, the all > geneme nuclear acid. > I don't know if dbiflat permits what i want to do, or i would use > another type of flat file?. We had the same request from Rodrigo Lopez at EBI a few weeks ago. We are thinking about the best way to do it. We have to make names for the "entries", and allow retrieval of single features. For CDS features we may want to index also as a protein database. Bacterial genomes are simple cases - we also have to consider eukaryote genomic contigs where CDSs are ascorr more than one entry. We hope to have a prototype available in the next release. How many other users are interested in indexing CDSs? Any suggestions for how to name the CDS "entries"? regards, Peter From michael.watson at bbsrc.ac.uk Mon Nov 27 08:57:46 2006 From: michael.watson at bbsrc.ac.uk (michael watson (IAH-C)) Date: Mon, 27 Nov 2006 13:57:46 -0000 Subject: [EMBOSS] Transeq and very large sequences Message-ID: <8975119BCD0AC5419D61A9CF1A923E9503E2E4A8@iahce2ksrv1.iah.bbsrc.ac.uk> Hi I want to translate very large (eukrayotic chromosomes!) DNA sequences in all 6 frames. Transeq takes about a day per large chromosome, running on a linux machine with 3Gb of RAM. Any suggestions on alternatives or how I could speed it up? Thanks Mick The information contained in this message may be confidential or legally privileged and is intended solely for the addressee. If you have received this message in error please delete it & notify the originator immediately. Unauthorised use, disclosure, copying or alteration of this message is forbidden & may be unlawful. The contents of this e-mail are the views of the sender and do not necessarily represent the views of the Institute. This email and associated attachments has been checked locally for viruses but we can accept no responsibility once it has left our systems. Communications on Institute computers are monitored to secure the effective operation of the systems and for other lawful purposes. From pmr at ebi.ac.uk Mon Nov 27 10:15:25 2006 From: pmr at ebi.ac.uk (Peter Rice) Date: Mon, 27 Nov 2006 15:15:25 +0000 Subject: [EMBOSS] Transeq and very large sequences In-Reply-To: <8975119BCD0AC5419D61A9CF1A923E9503E2E4A8@iahce2ksrv1.iah.bbsrc.ac.uk> References: <8975119BCD0AC5419D61A9CF1A923E9503E2E4A8@iahce2ksrv1.iah.bbsrc.ac.uk> Message-ID: <456B010D.6090807@ebi.ac.uk> michael watson (IAH-C) wrote: > I want to translate very large (eukrayotic chromosomes!) DNA sequences > in all 6 frames. Transeq takes about a day per large chromosome, > running on a linux machine with 3Gb of RAM. > > Any suggestions on alternatives or how I could speed it up? You want just a 6-frame translation of an entire chromosome? I will look into why it takes so long. We have made some changes to string size extension that may already help this for the next release. regards, Peter From michael.watson at bbsrc.ac.uk Mon Nov 27 10:47:17 2006 From: michael.watson at bbsrc.ac.uk (michael watson (IAH-C)) Date: Mon, 27 Nov 2006 15:47:17 -0000 Subject: [EMBOSS] Transeq and very large sequences In-Reply-To: <456B010D.6090807@ebi.ac.uk> Message-ID: <8975119BCD0AC5419D61A9CF1A923E9503E2E4AD@iahce2ksrv1.iah.bbsrc.ac.uk> Hi Peter Yes, a 6-frame translation of a chromosome :) It was meant to be part of a quick-and-dirty analysis method, but is proving to be anything but quick.... Mick -----Original Message----- From: Peter Rice [mailto:pmr at ebi.ac.uk] Sent: 27 November 2006 15:15 To: michael watson (IAH-C) Cc: emboss at lists.open-bio.org Subject: Re: [EMBOSS] Transeq and very large sequences michael watson (IAH-C) wrote: > I want to translate very large (eukrayotic chromosomes!) DNA sequences > in all 6 frames. Transeq takes about a day per large chromosome, > running on a linux machine with 3Gb of RAM. > > Any suggestions on alternatives or how I could speed it up? You want just a 6-frame translation of an entire chromosome? I will look into why it takes so long. We have made some changes to string size extension that may already help this for the next release. regards, Peter From michael.watson at bbsrc.ac.uk Mon Nov 27 11:32:25 2006 From: michael.watson at bbsrc.ac.uk (michael watson (IAH-C)) Date: Mon, 27 Nov 2006 16:32:25 -0000 Subject: [EMBOSS] Transeq and very large sequences In-Reply-To: Message-ID: <8975119BCD0AC5419D61A9CF1A923E9503E2E4B4@iahce2ksrv1.iah.bbsrc.ac.uk> Excellent! I set the MAXSEQIN paramter to 200,000,000 and it ran in 18 seconds.... -----Original Message----- From: David Mathog [mailto:mathog at caltech.edu] Sent: 27 November 2006 16:16 To: michael watson (IAH-C) Cc: emboss at lists.open-bio.org Subject: Re: [EMBOSS] Transeq and very large sequences On Mon, 27 Nov 2006, michael watson (IAH-C) wrote: > Hi > > I want to translate very large (eukrayotic chromosomes!) DNA sequences > in all 6 frames. Transeq takes about a day per large chromosome, > running on a linux machine with 3Gb of RAM. Well, you might try my fasttrans program. It may not do exactly what you want though. If the input sequence is bigger than 100kb it automatically fragments the input into 101kb chunks with a 1kb overlap. You could easily modify the code to make that chunk size so large that the whole chromosome would be read. I just tested it on Human chromosome 10 and it took 29 seconds on an Opteron system to do all 6 frames with the command: % time gunzip -c Homo_sapiens.NCBI36.41.dna.chromosome.10.fa.gz | fasttrans 123456 > foo.out ftp://saf.bio.caltech.edu/pub/software/molbio/fasttrans.c As for fixing the original problem, without looking at the code I'm going to hazard a wild guess. The program may be allocating smallish chunks for a buffer and then searching from the front of the buffer for the new end each time. This bug is never obvious when there are only a few chunks added but the time goes up as the square of the length if innumerable chunks must be added. So when presented with an input 100 times bigger than typical test cases the run time takes 10000 times longer, which sounds more or less like what you're seeing. Regards, David Mathog mathog at caltech.edu From pmr at ebi.ac.uk Mon Nov 27 11:59:49 2006 From: pmr at ebi.ac.uk (Peter Rice) Date: Mon, 27 Nov 2006 16:59:49 +0000 Subject: [EMBOSS] Transeq and very large sequences In-Reply-To: <8975119BCD0AC5419D61A9CF1A923E9503E2E4B4@iahce2ksrv1.iah.bbsrc.ac.uk> References: <8975119BCD0AC5419D61A9CF1A923E9503E2E4B4@iahce2ksrv1.iah.bbsrc.ac.uk> Message-ID: <456B1985.8080305@ebi.ac.uk> michael watson (IAH-C) wrote: > Excellent! I set the MAXSEQIN paramter to 200,000,000 and it ran in 18 > seconds.... Ah, that is a challenge. I'll see what I can do with the EMBOSS code :-) regards, Peter From mathog at caltech.edu Mon Nov 27 15:06:06 2006 From: mathog at caltech.edu (David Mathog) Date: Mon, 27 Nov 2006 12:06:06 -0800 Subject: [EMBOSS] Transeq and very large sequences Message-ID: On Mon, 27 Nov 2006, michael watson (IAH-C) wrote: > Hi > > I want to translate very large (eukrayotic chromosomes!) DNA sequences > in all 6 frames. Transeq takes about a day per large chromosome, > running on a linux machine with 3Gb of RAM. Well, you might try my fasttrans program. It may not do exactly what you want though. If the input sequence is bigger than 100kb it automatically fragments the input into 101kb chunks with a 1kb overlap. You could easily modify the code to make that chunk size so large that the whole chromosome would be read. I just tested it on Human chromosome 10 and it took 29 seconds on an Opteron system to do all 6 frames with the command: % time gunzip -c Homo_sapiens.NCBI36.41.dna.chromosome.10.fa.gz | fasttrans 123456 > foo.out ftp://saf.bio.caltech.edu/pub/software/molbio/fasttrans.c As for fixing the original problem, without looking at the code I'm going to hazard a wild guess. The program may be allocating smallish chunks for a buffer and then searching from the front of the buffer for the new end each time. This bug is never obvious when there are only a few chunks added but the time goes up as the square of the length if innumerable chunks must be added. So when presented with an input 100 times bigger than typical test cases the run time takes 10000 times longer, which sounds more or less like what you're seeing. Regards, David Mathog mathog at caltech.edu Manager, Sequence Analysis Facility, Biology Division, Caltech From tsirigos at gmail.com Tue Nov 28 15:17:10 2006 From: tsirigos at gmail.com (Aristotelis Tsirigos) Date: Tue, 28 Nov 2006 15:17:10 -0500 Subject: [EMBOSS] EMBOSS database setup Message-ID: <639b80db0611281217i6c1cc927v50ac9b8e6a71717c@mail.gmail.com> I just installed EMBOSS on my laptop by compiling the source codes under cygwin. Then, I tried to follow the online tutorial, but I encountered several problems. The main problem is that I don't have access to any of the databases, so I am wondering if there is a need for some kind of configuration. For example, showdb was initially showing no databases, until I renamed file ' emboss.default.template' to 'emboss.default'. Then, it showed some databases such as genbank. But when I used seqret to retrieve an entry from that database, it doesn't find anything... Is there a need for database configuration? Is it not possible to access databases remotely? Is there any tutorial that explains how to properly setup your data? Thanks! Aris From maoj at helix.nih.gov Thu Nov 30 08:57:24 2006 From: maoj at helix.nih.gov (Jean Mao) Date: Thu, 30 Nov 2006 08:57:24 -0500 Subject: [EMBOSS] Question regarding Reference Sequence Database Message-ID: <000001c71487$76d7e7b0$be4de780@CIT.NIH.GOV> Hi, Does any program in EMBOSS package can make use of the Reference Sequence Databases? I indexed refseq databases with dbxflat and run showfeat against them but receive error about has zero length sequence : Warning: Sequence 'refseqnt-id:NG_002612' has zero length, ignored Error: Unable to read sequence 'refseqnt:NG_002612' Thanks! Jean From pmr at ebi.ac.uk Thu Nov 30 09:36:06 2006 From: pmr at ebi.ac.uk (Peter Rice) Date: Thu, 30 Nov 2006 14:36:06 +0000 Subject: [EMBOSS] Question regarding Reference Sequence Database In-Reply-To: <000001c71487$76d7e7b0$be4de780@CIT.NIH.GOV> References: <000001c71487$76d7e7b0$be4de780@CIT.NIH.GOV> Message-ID: <456EEC56.5090108@ebi.ac.uk> Hi Jean, > Does any program in EMBOSS package can make use of the Reference Sequence > Databases? I indexed refseq databases with dbxflat and run showfeat against > them but receive error about has zero length sequence : The next release will include refseq as a valid sequence format. You can usually get away with defining the format as Genbank. If that does not work please let me know and I will update the refseq format code. Aha ... but in this case ... NG_002612 does have zero length. This appears to be one of those entries (the EMBL CON division does much the same) that only refer to sequence data in other entries. It ends with the line: CONTIG join(complement(AC006998.3:2483..110100)) We can try to process these. The database defintion will need to know where to look up "AC006998.3" which is where the sequence data ... and all the missing features ... should be. Can you exclude the CON entries from your indexing? if not, we can try excluding them. Hope that helps, Peter From simon.andrews at bbsrc.ac.uk Thu Nov 30 09:33:40 2006 From: simon.andrews at bbsrc.ac.uk (Simon Andrews) Date: Thu, 30 Nov 2006 14:33:40 +0000 Subject: [EMBOSS] Question regarding Reference Sequence Database In-Reply-To: <000001c71487$76d7e7b0$be4de780@CIT.NIH.GOV> References: <000001c71487$76d7e7b0$be4de780@CIT.NIH.GOV> Message-ID: On 30 Nov 2006, at 13:57, Jean Mao wrote: > Hi, > > Does any program in EMBOSS package can make use of the Reference > Sequence > Databases? I indexed refseq databases with dbxflat and run showfeat > against > them but receive error about has zero length sequence : > > Warning: Sequence 'refseqnt-id:NG_002612' has zero length, ignored > Error: > Unable to read sequence 'refseqnt:NG_002612' NG_ sequences in refseq are a bit odd. They're not real sequences but a virtual collection of other sequences which are joined together to make longer assemblies. The records themselves don't actually contain any sequence (hence the zero length sequence error), just pointers to parts of other sequences. On the NCBI website they have a facility to join the fragments together to create a 'real' sequence from them. You could probably do this if you had all the underlying sequences available, but it's not something which is likely to be possible during indexing. EMBOSS works fine with normal refseq files, but these virtual files are not something I'd say it was reasonable for it to cope with. It would be nice if NCBI offered an option to download rendered versions of these sequences, but as many of them are pretty big it might be a very large data set. TTFN Simon. From uludag at ebi.ac.uk Thu Nov 30 10:57:15 2006 From: uludag at ebi.ac.uk (Mahmut Uludag) Date: Thu, 30 Nov 2006 15:57:15 +0000 Subject: [EMBOSS] EMBOSS database setup In-Reply-To: <639b80db0611281217i6c1cc927v50ac9b8e6a71717c@mail.gmail.com> References: <639b80db0611281217i6c1cc927v50ac9b8e6a71717c@mail.gmail.com> Message-ID: <1164902235.14146.57.camel@emboss2.ebi.ac.uk> Hi Aris, > I just installed EMBOSS on my laptop by compiling the source codes under > cygwin. Then, I tried to follow the online tutorial, but I encountered > several problems. The main problem is that I don't have access to any of the > databases, so I am wondering if there is a need for some kind of > configuration. For example, showdb was initially showing no databases, until > I renamed file ' emboss.default.template' to 'emboss.default'. Then, it > showed some databases such as genbank. But when I used seqret to retrieve an > entry from that database, it doesn't find anything... Is there a need for > database configuration? Is it not possible to access databases remotely? Is > there any tutorial that explains how to properly setup your data? I thought the following message posted few days before your message may answer some of your questions. http://emboss.open-bio.org/pipermail/emboss/2006-November/002774.html Regards, Mahmut From ajb at ebi.ac.uk Thu Nov 30 11:27:40 2006 From: ajb at ebi.ac.uk (ajb at ebi.ac.uk) Date: Thu, 30 Nov 2006 16:27:40 -0000 (GMT) Subject: [EMBOSS] EMBOSS database setup In-Reply-To: <1164902235.14146.57.camel@emboss2.ebi.ac.uk> References: <639b80db0611281217i6c1cc927v50ac9b8e6a71717c@mail.gmail.com> <1164902235.14146.57.camel@emboss2.ebi.ac.uk> Message-ID: <43964.81.98.244.247.1164904060.squirrel@webmail.ebi.ac.uk> The appended definitions are simple ones that may be useful if you only want a few sequences at a time. If sites upgrade to SRS8 then alter accordingly. Alan DB embl [ type: N method: srswww format: embl release: "EBI" url: "http://srs.ebi.ac.uk/srs7bin/cgi-bin/wgetz" comment: "EMBL from the EBI" ] DB em [ type: N method: srswww format: embl release: "EBI" url: "http://srs.ebi.ac.uk/srs7bin/cgi-bin/wgetz" dbalias: "EMBL" comment: "EMBL from the EBI" ] DB swissprot [ type: P method: srswww format: swiss release: "EBI" url: "http://srs.ebi.ac.uk/srs7bin/cgi-bin/wgetz" comment: "SWISSPROT from the EBI" ] DB sw [ type: P method: srswww format: swiss release: "EBI" url: "http://srs.ebi.ac.uk/srs7bin/cgi-bin/wgetz" dbalias: "SWISSPROT" comment: "SWISSPROT from the EBI" ] DB uniprot [ type: P method: srswww format: swiss release: "EBI" url: "http://srs.ebi.ac.uk/srs7bin/cgi-bin/wgetz" comment: "UNIPROT from the EBI" ] DB uni [ type: P method: srswww format: swiss release: EBI url: "http://srs.ebi.ac.uk/srs7bin/cgi-bin/wgetz" dbalias: "UNIPROT" comment: "UNIPROT from the EBI" ] DB pir [ type: P method: srswww format: nbrf release: "EBI" url: "http://srs.ebi.ac.uk/srs7bin/cgi-bin/wgetz" comment: "PIR from the EBI" ] DB genbank [ type: N method: srswww format: genbank release: "NCBI" url: "http://www.infobiogen.fr/srs7bin/cgi-bin/wgetz" comment: "GenBank from Infobiogen" ] DB gb [ type: N method: srswww format: genbank release: "NCBI" url: "http://www.infobiogen.fr/srs7bin/cgi-bin/wgetz" dbalias: "GENBANK" comment: "GenBank from Infobiogen" ] DB refseq [ type: N method: srswww format: genbank release: "NCBI" url: "http://srs.ebi.ac.uk/srs7bin/cgi-bin/wgetz" comment: "REFSEQ from EBI" ] From David.Bauer at SCHERING.DE Wed Nov 1 07:21:07 2006 From: David.Bauer at SCHERING.DE (David.Bauer at SCHERING.DE) Date: Wed, 1 Nov 2006 08:21:07 +0100 Subject: [EMBOSS] Batch retrieval of taxonomy/species names using entret..... In-Reply-To: <45479B8C.5080800@ebi.ac.uk> Message-ID: If you want to parse Swissprot files which you get from entret, you could have a look at Swissknife, which is "An object-oriented Perl library to handle Swiss-Prot entries": http://swissknife.sourceforge.net/docs/ This can be used to access all header information in sprot files, also the information in the special format CC lines. David. emboss-bounces at lists.open-bio.org schrieb am 31/10/2006 19:53:00: > Hi Richard, > > Richard Rothery wrote: > > I am interested in using entret to retrieve single field entries from > > swissprot or sptrembl. Specifically, I would like to feed entret a list > > of accessions and have it return a file with the species names and/or > > taxonomies. I intend to use this information to compare with my > > phylogeny analyses of clustalw alignments. > > EMBOSS stores the full text in entret without parsing. > > We could try to extract specific fields but it is not easy to definethem for > all formats. > > You can do this with SRS. Try the EBI server for example: > > Go to the library page > > Select UniProtKB/SwissProt (or UniProtKB/TrEMBL) > > Select "standard query form" > > Enter your query in the top part (e.g. accession number) > > In the "create a view" section click the "list" button to egt the original > lines. Select anything taxonomic from the pull down list (control-click to > select more than one) > > Press "search". > > refine your query. You will see the URL at the top that can be used > to retrieve > data when you are happy. > > Failing that, you could just parse out the ID and O* lines from > entret using a > simple perl script. > > Hope that helps, > > Peter > > _______________________________________________ > EMBOSS mailing list > EMBOSS at lists.open-bio.org > http://lists.open-bio.org/mailman/listinfo/emboss From msarachu at biol.unlp.edu.ar Wed Nov 1 22:30:03 2006 From: msarachu at biol.unlp.edu.ar (=?ISO-8859-1?Q?Mart=EDn_Sarachu?=) Date: Wed, 01 Nov 2006 19:30:03 -0300 Subject: [EMBOSS] wEMBOSS-1.7.0 released Message-ID: <45491FEB.2070902@biol.unlp.edu.ar> This release is compatible both with EMBOSS-4 and 3. A few bugs fixed and some new features in this version. wrappers4EMBOSS-1.5 is distributed with this release as an optional to install. wEMBOSS can be downloaded from http://www.wemboss.org Best regards, The wEMBOSS team From molatwork at yahoo.es Thu Nov 2 08:00:20 2006 From: molatwork at yahoo.es (Miguel Ortiz Lombardia) Date: Thu, 02 Nov 2006 09:00:20 +0100 Subject: [EMBOSS] [Fwd: [Staden] Re: using emboss programs from spin] Message-ID: <4549A594.4050205@yahoo.es> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear all, A few weeks ago I sent a message to the Staden mailing list asking for support on its interface to EMBOSS. I was given advice on how to get it kind of working (thanks to Guy Bottu!) but I was also told that due to the cut of the support for the Staden team, the improved version of spin (spin2) was not fully developed. Therefore, the Staden interface for EMBOSS is incomplete. Here, a number of users are quite afraid of the command line ;-{ so they would appreciate a graphic interface to EMBOSS. We tried Jemboss first, but got a number of problems that we couldn't solve (essentially with some results text files being corrupted). Then, I met with this interface from the Staden package, and found it very useful, to a certain extent. Hence, advised by Guy and Peter Rice, I hereby show our interest :) in such an interface, which would combine the goodies of two excellent packages. Thank you very much for your good work. Cheers, Miguel - -- Miguel Ortiz Lombard?a Centro de Investigaciones Oncol?gicas C/ Melchor Fern?ndez Almagro, 3 28029 Madrid, Spain Tel. +34 912 246 900 Fax. +34 912 246 976 email: molatwork at yahoo.es www: http://www.ysbl.york.ac.uk/~mol/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Le travail est ce que l'homme a trouv? de mieux pour ne rien faire de sa vie. (Raoul Vaneigem) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFFSaWTF6oOrDvhbQIRAqL+AKClBRlA1gI41N3vMUB7QcvAd7kzoQCfVJ5b K2c6TvGITSmm3mkBl8nf8jY= =4zxW -----END PGP SIGNATURE----- -------------- next part -------------- An embedded message was scrubbed... From: Peter Rice Subject: [Staden] Re: using emboss programs from spin Date: Wed, 01 Nov 2006 12:03:42 +0000 Size: 4043 URL: From bernd.web at gmail.com Thu Nov 2 16:16:28 2006 From: bernd.web at gmail.com (Bernd Web) Date: Thu, 2 Nov 2006 17:16:28 +0100 Subject: [EMBOSS] IDs in output Message-ID: <716af09c0611020816r3d5c30dg1b1c6f1f4d5fea5d@mail.gmail.com> Hi, Sometimes I use an EMBOSS command directly on a FastA file. I wonder if it is possible to select the ID used in the output, esp for FastA records with an NCBI defline. >gi|248166|g|AA21972.1| description... in the output of an EMBOSS command becomes: AA21972.1| It would be very easy if the ID could be chosen to be the GI number. Now the ID used depends on the GI record (sp, pdb, pir) show different IDs in EMBOSS output. Is this possible to choose the fixed GI number as record ID? Regards, Bernd From smiddha at indiana.edu Thu Nov 2 15:49:42 2006 From: smiddha at indiana.edu (Sumit Middha) Date: Thu, 02 Nov 2006 10:49:42 -0500 Subject: [EMBOSS] Emboss-explorer error Message-ID: <454A1396.3020501@indiana.edu> Hi, I have setup emboss-explorer and it works fine for most of the tools. However, fuzznuc, fuzztran seem to give an error (unknown datatype pattern). Server logs: [Wed Nov 01 12:51:52 2006] [error] [client 156.56.96.41] unknown datatype pattern in fuzznuc at /bioportal/web/tools/emboss-explorer/lib/EMBOSS/GUI.pm line 246, referer: http://bioportal.cgb.indiana.edu/cgi-bin/emboss/menu linked from - http://bioportal.cgb.indiana.edu/cgi-bin/emboss/fuzznuc fuzznuc works fine from command line. Thanks, Sumit From smiddha at indiana.edu Thu Nov 2 15:49:26 2006 From: smiddha at indiana.edu (Sumit Middha) Date: Thu, 02 Nov 2006 10:49:26 -0500 Subject: [EMBOSS] Error: Invalid graph value 'png' In-Reply-To: References: Message-ID: <454A1386.2000001@indiana.edu> > Hi, > > I used the command to make sure it finds and installs with png option > ./configure --prefix=/bioportal/sw/encap/emboss-4.0.0 > --with-pngdriver=/local > > However, it still does not include png in the Graph type. Its a > solaris machine I work on > > > uname -a > SunOS helix 5.10 Generic_118833-22 sun4u sparc SUNW,Sun-Fire-480R > > > ls /local/lib/*png* > /local/lib/libpng.a /local/lib/libpng12.a > /local/lib/libpng.so /local/lib/libpng12.so > /local/lib/libpng.so.3 /local/lib/libpng12.so.0 > /local/lib/libpng.so.3.1.2.7 /local/lib/libpng12.so.0.1.2.7 > > > ls /local/include/*png* > /local/include/png.h /local/include/pngconf.h > > /local/include/libpng: > png.h pngconf.h > > /local/include/libpng12: > png.h pngconf.h > > Can someone please suggest a way out ? > > Thanks, > Sumit > ------------------------------------------------------------------------ > > This file contains any messages produced by compilers while > running configure, to aid debugging if configure makes a mistake. > > It was created by configure, which was > generated by GNU Autoconf 2.59. Invocation command line was > > $ ./configure --prefix=/bioportal/sw/encap/emboss-4.0.0 --with-pngdriver=/local > > ## --------- ## > ## Platform. ## > ## --------- ## > > hostname = helix > uname -m = sun4u > uname -r = 5.10 > uname -s = SunOS > uname -v = Generic_118833-22 > > /usr/bin/uname -p = sparc > /bin/uname -X = System = SunOS > Node = helix > Release = 5.10 > KernelID = Generic_118833-22 > Machine = sun4u > BusType = > Serial = > Users = > OEM# = 0 > Origin# = 1 > NumCPU = 4 > > /bin/arch = sun4 > /usr/bin/arch -k = sun4u > /usr/convex/getsysinfo = unknown > hostinfo = unknown > /bin/machine = unknown > /usr/bin/oslevel = unknown > /bin/universe = unknown > > PATH: /local/bin > PATH: /bin > PATH: /usr/bin > PATH: /usr/ccs/bin > PATH: /opt/SUNWspro/bin > PATH: local/sbin > PATH: /usr/sbin > PATH: /sbin > PATH: /local/bin > PATH: /usr/bin > PATH: /usr/ccs/bin > PATH: /usr/openwin/bin > > > ## ----------- ## > ## Core tests. ## > ## ----------- ## > > configure:1557: checking for a BSD-compatible install > configure:1612: result: /local/bin/install -c > configure:1623: checking whether build environment is sane > configure:1666: result: yes > configure:1731: checking for gawk > configure:1747: found /local/bin/gawk > configure:1757: result: gawk > configure:1767: checking whether make sets $(MAKE) > configure:1787: result: yes > configure:1961: checking for gawk > configure:1987: result: gawk > configure:2044: checking for gcc > configure:2060: found /local/bin/gcc > configure:2070: result: gcc > configure:2314: checking for C compiler version > configure:2317: gcc --version &5 > gcc (GCC) 3.4.4 > Copyright (C) 2004 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > configure:2320: $? = 0 > configure:2322: gcc -v &5 > Reading specs from /local/encap/gcc-3.4.4/lib/gcc/sparc-sun-solaris2.10/3.4.4/specs > Configured with: ./configure --prefix=/local/encap/gcc-3.4.4 --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-shared > Thread model: posix > gcc version 3.4.4 > configure:2325: $? = 0 > configure:2327: gcc -V &5 > gcc: `-V' option must have argument > configure:2330: $? = 1 > configure:2353: checking for C compiler default output file name > configure:2356: gcc conftest.c >&5 > configure:2359: $? = 0 > configure:2405: result: a.out > configure:2410: checking whether the C compiler works > configure:2416: ./a.out > configure:2419: $? = 0 > configure:2436: result: yes > configure:2443: checking whether we are cross compiling > configure:2445: result: no > configure:2448: checking for suffix of executables > configure:2450: gcc -o conftest conftest.c >&5 > configure:2453: $? = 0 > configure:2478: result: > configure:2484: checking for suffix of object files > configure:2505: gcc -c conftest.c >&5 > configure:2508: $? = 0 > configure:2530: result: o > configure:2534: checking whether we are using the GNU C compiler > configure:2558: gcc -c conftest.c >&5 > configure:2564: $? = 0 > configure:2568: test -z > || test ! -s conftest.err > configure:2571: $? = 0 > configure:2574: test -s conftest.o > configure:2577: $? = 0 > configure:2590: result: yes > configure:2596: checking whether gcc accepts -g > configure:2617: gcc -c -g conftest.c >&5 > configure:2623: $? = 0 > configure:2627: test -z > || test ! -s conftest.err > configure:2630: $? = 0 > configure:2633: test -s conftest.o > configure:2636: $? = 0 > configure:2647: result: yes > configure:2664: checking for gcc option to accept ANSI C > configure:2734: gcc -c conftest.c >&5 > configure:2740: $? = 0 > configure:2744: test -z > || test ! -s conftest.err > configure:2747: $? = 0 > configure:2750: test -s conftest.o > configure:2753: $? = 0 > configure:2771: result: none needed > configure:2789: gcc -c conftest.c >&5 > conftest.c:2: error: syntax error before "me" > configure:2795: $? = 1 > configure: failed program was: > | #ifndef __cplusplus > | choke me > | #endif > configure:2939: checking for style of include used by make > configure:2967: result: GNU > configure:2995: checking dependency style of gcc > configure:3085: result: gcc3 > configure:3107: checking how to run the C preprocessor > configure:3142: gcc -E conftest.c > configure:3148: $? = 0 > configure:3180: gcc -E conftest.c > conftest.c:11:28: ac_nonexistent.h: No such file or directory > configure:3186: $? = 1 > configure: failed program was: > | /* confdefs.h. */ > | > | #define PACKAGE_NAME "" > | #define PACKAGE_TARNAME "" > | #define PACKAGE_VERSION "" > | #define PACKAGE_STRING "" > | #define PACKAGE_BUGREPORT "" > | #define PACKAGE "EMBOSS" > | #define VERSION "4.0.0" > | /* end confdefs.h. */ > | #include > configure:3225: result: gcc -E > configure:3249: gcc -E conftest.c > configure:3255: $? = 0 > configure:3287: gcc -E conftest.c > conftest.c:11:28: ac_nonexistent.h: No such file or directory > configure:3293: $? = 1 > configure: failed program was: > | /* confdefs.h. */ > | > | #define PACKAGE_NAME "" > | #define PACKAGE_TARNAME "" > | #define PACKAGE_VERSION "" > | #define PACKAGE_STRING "" > | #define PACKAGE_BUGREPORT "" > | #define PACKAGE "EMBOSS" > | #define VERSION "4.0.0" > | /* end confdefs.h. */ > | #include > configure:3596: checking build system type > configure:3614: result: sparc-sun-solaris2.10 > configure:3622: checking host system type > configure:3636: result: sparc-sun-solaris2.10 > configure:3644: checking for a sed that does not truncate output > configure:3698: result: /local/bin/sed > configure:3701: checking for egrep > configure:3711: result: grep -E > configure:3727: checking for ld used by gcc > configure:3794: result: /usr/ccs/bin/ld > configure:3803: checking if the linker (/usr/ccs/bin/ld) is GNU ld > configure:3818: result: no > configure:3823: checking for /usr/ccs/bin/ld option to reload object files > configure:3830: result: -r > configure:3848: checking for BSD-compatible nm > configure:3897: result: /usr/ccs/bin/nm -p > configure:3901: checking whether ln -s works > configure:3905: result: yes > configure:3912: checking how to recognise dependent libraries > configure:4088: result: pass_all > configure:4297: gcc -c -O2 -D__EXTENSIONS__ conftest.c >&5 > configure:4300: $? = 0 > configure:4321: checking for ANSI C header files > configure:4346: gcc -c -O2 -D__EXTENSIONS__ conftest.c >&5 > configure:4352: $? = 0 > configure:4356: test -z > || test ! -s conftest.err > configure:4359: $? = 0 > configure:4362: test -s conftest.o > configure:4365: $? = 0 > configure:4454: gcc -o conftest -O2 -D__EXTENSIONS__ conftest.c >&5 > configure:4457: $? = 0 > configure:4459: ./conftest > configure:4462: $? = 0 > configure:4477: result: yes > configure:4501: checking for sys/types.h > configure:4517: gcc -c -O2 -D__EXTENSIONS__ conftest.c >&5 > configure:4523: $? = 0 > configure:4527: test -z > || test ! -s conftest.err > configure:4530: $? = 0 > configure:4533: test -s conftest.o > configure:4536: $? = 0 > configure:4547: result: yes > configure:4501: checking for sys/stat.h > configure:4517: gcc -c -O2 -D__EXTENSIONS__ conftest.c >&5 > configure:4523: $? = 0 > configure:4527: test -z > || test ! -s conftest.err > configure:4530: $? = 0 > configure:4533: test -s conftest.o > configure:4536: $? = 0 > configure:4547: result: yes > configure:4501: checking for stdlib.h > configure:4517: gcc -c -O2 -D__EXTENSIONS__ conftest.c >&5 > configure:4523: $? = 0 > configure:4527: test -z > || test ! -s conftest.err > configure:4530: $? = 0 > configure:4533: test -s conftest.o > configure:4536: $? = 0 > configure:4547: result: yes > configure:4501: checking for string.h > configure:4517: gcc -c -O2 -D__EXTENSIONS__ conftest.c >&5 > configure:4523: $? = 0 > configure:4527: test -z > || test ! -s conftest.err > configure:4530: $? = 0 > configure:4533: test -s conftest.o > configure:4536: $? = 0 > configure:4547: result: yes > configure:4501: checking for memory.h > configure:4517: gcc -c -O2 -D__EXTENSIONS__ conftest.c >&5 > configure:4523: $? = 0 > configure:4527: test -z > || test ! -s conftest.err > configure:4530: $? = 0 > configure:4533: test -s conftest.o > configure:4536: $? = 0 > configure:4547: result: yes > configure:4501: checking for strings.h > configure:4517: gcc -c -O2 -D__EXTENSIONS__ conftest.c >&5 > configure:4523: $? = 0 > configure:4527: test -z > || test ! -s conftest.err > configure:4530: $? = 0 > configure:4533: test -s conftest.o > configure:4536: $? = 0 > configure:4547: result: yes > configure:4501: checking for inttypes.h > configure:4517: gcc -c -O2 -D__EXTENSIONS__ conftest.c >&5 > configure:4523: $? = 0 > configure:4527: test -z > || test ! -s conftest.err > configure:4530: $? = 0 > configure:4533: test -s conftest.o > configure:4536: $? = 0 > configure:4547: result: yes > configure:4501: checking for stdint.h > configure:4517: gcc -c -O2 -D__EXTENSIONS__ conftest.c >&5 > configure:4523: $? = 0 > configure:4527: test -z > || test ! -s conftest.err > configure:4530: $? = 0 > configure:4533: test -s conftest.o > configure:4536: $? = 0 > configure:4547: result: yes > configure:4501: checking for unistd.h > configure:4517: gcc -c -O2 -D__EXTENSIONS__ conftest.c >&5 > configure:4523: $? = 0 > configure:4527: test -z > || test ! -s conftest.err > configure:4530: $? = 0 > configure:4533: test -s conftest.o > configure:4536: $? = 0 > configure:4547: result: yes > configure:4573: checking dlfcn.h usability > configure:4585: gcc -c -O2 -D__EXTENSIONS__ conftest.c >&5 > configure:4591: $? = 0 > configure:4595: test -z > || test ! -s conftest.err > configure:4598: $? = 0 > configure:4601: test -s conftest.o > configure:4604: $? = 0 > configure:4614: result: yes > configure:4618: checking dlfcn.h presence > configure:4628: gcc -E conftest.c > configure:4634: $? = 0 > configure:4654: result: yes > configure:4689: checking for dlfcn.h > configure:4696: result: yes > configure:4761: checking for g++ > configure:4777: found /local/bin/g++ > configure:4787: result: g++ > configure:4803: checking for C++ compiler version > configure:4806: g++ --version &5 > g++ (GCC) 3.4.4 > Copyright (C) 2004 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > configure:4809: $? = 0 > configure:4811: g++ -v &5 > Reading specs from /local/encap/gcc-3.4.4/lib/gcc/sparc-sun-solaris2.10/3.4.4/specs > Configured with: ./configure --prefix=/local/encap/gcc-3.4.4 --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-shared > Thread model: posix > gcc version 3.4.4 > configure:4814: $? = 0 > configure:4816: g++ -V &5 > g++: `-V' option must have argument > configure:4819: $? = 1 > configure:4822: checking whether we are using the GNU C++ compiler > configure:4846: g++ -c conftest.cc >&5 > configure:4852: $? = 0 > configure:4856: test -z > || test ! -s conftest.err > configure:4859: $? = 0 > configure:4862: test -s conftest.o > configure:4865: $? = 0 > configure:4878: result: yes > configure:4884: checking whether g++ accepts -g > configure:4905: g++ -c -g conftest.cc >&5 > configure:4911: $? = 0 > configure:4915: test -z > || test ! -s conftest.err > configure:4918: $? = 0 > configure:4921: test -s conftest.o > configure:4924: $? = 0 > configure:4935: result: yes > configure:4977: g++ -c -g -O2 conftest.cc >&5 > configure:4983: $? = 0 > configure:4987: test -z > || test ! -s conftest.err > configure:4990: $? = 0 > configure:4993: test -s conftest.o > configure:4996: $? = 0 > configure:5022: g++ -c -g -O2 conftest.cc >&5 > conftest.cc: In function `int main()': > conftest.cc:26: error: `exit' undeclared (first use this function) > conftest.cc:26: error: (Each undeclared identifier is reported only once for each function it appears in.) > configure:5028: $? = 1 > configure: failed program was: > | /* confdefs.h. */ > | > | #define PACKAGE_NAME "" > | #define PACKAGE_TARNAME "" > | #define PACKAGE_VERSION "" > | #define PACKAGE_STRING "" > | #define PACKAGE_BUGREPORT "" > | #define PACKAGE "EMBOSS" > | #define VERSION "4.0.0" > | #define STDC_HEADERS 1 > | #define HAVE_SYS_TYPES_H 1 > | #define HAVE_SYS_STAT_H 1 > | #define HAVE_STDLIB_H 1 > | #define HAVE_STRING_H 1 > | #define HAVE_MEMORY_H 1 > | #define HAVE_STRINGS_H 1 > | #define HAVE_INTTYPES_H 1 > | #define HAVE_STDINT_H 1 > | #define HAVE_UNISTD_H 1 > | #define HAVE_DLFCN_H 1 > | /* end confdefs.h. */ > | > | int > | main () > | { > | exit (42); > | ; > | return 0; > | } > configure:4977: g++ -c -g -O2 conftest.cc >&5 > configure:4983: $? = 0 > configure:4987: test -z > || test ! -s conftest.err > configure:4990: $? = 0 > configure:4993: test -s conftest.o > configure:4996: $? = 0 > configure:5022: g++ -c -g -O2 conftest.cc >&5 > configure:5028: $? = 0 > configure:5032: test -z > || test ! -s conftest.err > configure:5035: $? = 0 > configure:5038: test -s conftest.o > configure:5041: $? = 0 > configure:5066: checking dependency style of g++ > configure:5156: result: gcc3 > configure:5183: checking how to run the C++ preprocessor > configure:5214: g++ -E conftest.cc > configure:5220: $? = 0 > configure:5252: g++ -E conftest.cc > conftest.cc:25:28: ac_nonexistent.h: No such file or directory > configure:5258: $? = 1 > configure: failed program was: > | /* confdefs.h. */ > | > | #define PACKAGE_NAME "" > | #define PACKAGE_TARNAME "" > | #define PACKAGE_VERSION "" > | #define PACKAGE_STRING "" > | #define PACKAGE_BUGREPORT "" > | #define PACKAGE "EMBOSS" > | #define VERSION "4.0.0" > | #define STDC_HEADERS 1 > | #define HAVE_SYS_TYPES_H 1 > | #define HAVE_SYS_STAT_H 1 > | #define HAVE_STDLIB_H 1 > | #define HAVE_STRING_H 1 > | #define HAVE_MEMORY_H 1 > | #define HAVE_STRINGS_H 1 > | #define HAVE_INTTYPES_H 1 > | #define HAVE_STDINT_H 1 > | #define HAVE_UNISTD_H 1 > | #define HAVE_DLFCN_H 1 > | #ifdef __cplusplus > | extern "C" void std::exit (int) throw (); using std::exit; > | #endif > | /* end confdefs.h. */ > | #include > configure:5297: result: g++ -E > configure:5321: g++ -E conftest.cc > configure:5327: $? = 0 > configure:5359: g++ -E conftest.cc > conftest.cc:25:28: ac_nonexistent.h: No such file or directory > configure:5365: $? = 1 > configure: failed program was: > | /* confdefs.h. */ > | > | #define PACKAGE_NAME "" > | #define PACKAGE_TARNAME "" > | #define PACKAGE_VERSION "" > | #define PACKAGE_STRING "" > | #define PACKAGE_BUGREPORT "" > | #define PACKAGE "EMBOSS" > | #define VERSION "4.0.0" > | #define STDC_HEADERS 1 > | #define HAVE_SYS_TYPES_H 1 > | #define HAVE_SYS_STAT_H 1 > | #define HAVE_STDLIB_H 1 > | #define HAVE_STRING_H 1 > | #define HAVE_MEMORY_H 1 > | #define HAVE_STRINGS_H 1 > | #define HAVE_INTTYPES_H 1 > | #define HAVE_STDINT_H 1 > | #define HAVE_UNISTD_H 1 > | #define HAVE_DLFCN_H 1 > | #ifdef __cplusplus > | extern "C" void std::exit (int) throw (); using std::exit; > | #endif > | /* end confdefs.h. */ > | #include > configure:5462: checking for g77 > configure:5478: found /local/bin/g77 > configure:5488: result: g77 > configure:5503: checking for Fortran 77 compiler version > configure:5506: g77 --version &5 > GNU Fortran (GCC) 3.4.4 > Copyright (C) 2004 Free Software Foundation, Inc. > > GNU Fortran comes with NO WARRANTY, to the extent permitted by law. > You may redistribute copies of GNU Fortran > under the terms of the GNU General Public License. > For more information about these matters, see the file named COPYING > or type the command `info -f g77 Copying'. > configure:5509: $? = 0 > configure:5511: g77 -v &5 > Reading specs from /local/encap/gcc-3.4.4/lib/gcc/sparc-sun-solaris2.10/3.4.4/specs > Configured with: ./configure --prefix=/local/encap/gcc-3.4.4 --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-shared > Thread model: posix > gcc version 3.4.4 > configure:5514: $? = 0 > configure:5516: g77 -V &5 > g77: `-V' option must have argument > configure:5519: $? = 1 > configure:5527: checking whether we are using the GNU Fortran 77 compiler > configure:5541: g77 -c conftest.F >&5 > configure:5547: $? = 0 > configure:5551: test -z > || test ! -s conftest.err > configure:5554: $? = 0 > configure:5557: test -s conftest.o > configure:5560: $? = 0 > configure:5573: result: yes > configure:5579: checking whether g77 accepts -g > configure:5591: g77 -c -g conftest.f >&5 > configure:5597: $? = 0 > configure:5601: test -z > || test ! -s conftest.err > configure:5604: $? = 0 > configure:5607: test -s conftest.o > configure:5610: $? = 0 > configure:5622: result: yes > configure:5652: checking the maximum length of command line arguments > configure:5761: result: 262144 > configure:5772: checking command to parse /usr/ccs/bin/nm -p output from gcc object > configure:5877: gcc -c -O2 -D__EXTENSIONS__ conftest.c >&5 > configure:5880: $? = 0 > configure:5884: /usr/ccs/bin/nm -p conftest.o \| sed -n -e 's/^.*[ ]\([BDRT][BDRT]*\)[ ][ ]*\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2 \2/p' \> conftest.nm > configure:5887: $? = 0 > configure:5939: gcc -o conftest -O2 -D__EXTENSIONS__ conftest.c conftstm.o >&5 > configure:5942: $? = 0 > configure:5980: result: ok > configure:5984: checking for objdir > configure:5999: result: .libs > configure:6089: checking for ar > configure:6105: found /usr/ccs/bin/ar > configure:6116: result: ar > configure:6169: checking for ranlib > configure:6185: found /usr/ccs/bin/ranlib > configure:6196: result: ranlib > configure:6249: checking for strip > configure:6265: found /usr/ccs/bin/strip > configure:6276: result: strip > configure:6548: checking if gcc supports -fno-rtti -fno-exceptions > configure:6566: gcc -c -O2 -D__EXTENSIONS__ -fno-rtti -fno-exceptions conftest.c >&5 > cc1: warning: command line option "-fno-rtti" is valid for C++/ObjC++ but not for C > configure:6570: $? = 0 > configure:6583: result: no > configure:6598: checking for gcc option to produce PIC > configure:6808: result: -fPIC > configure:6816: checking if gcc PIC flag -fPIC works > configure:6834: gcc -c -O2 -D__EXTENSIONS__ -fPIC -DPIC conftest.c >&5 > configure:6838: $? = 0 > configure:6851: result: yes > configure:6879: checking if gcc static flag -static works > configure:6907: result: no > configure:6917: checking if gcc supports -c -o file.o > configure:6938: gcc -c -O2 -D__EXTENSIONS__ -o out/conftest2.o conftest.c >&5 > configure:6942: $? = 0 > configure:6964: result: yes > configure:6990: checking whether the gcc linker (/usr/ccs/bin/ld) supports shared libraries > configure:7948: result: yes > configure:7969: checking whether -lc should be explicitly linked in > configure:7974: gcc -c -O2 -D__EXTENSIONS__ conftest.c >&5 > configure:7977: $? = 0 > configure:7992: gcc -shared -Wl,-h -Wl,conftest -o conftest conftest.o -v 2\>\&1 \| grep -lc \>/dev/null 2\>\&1 > configure:7995: $? = 1 > configure:8007: result: yes > configure:8015: checking dynamic linker characteristics > configure:8624: result: solaris2.10 ld.so > configure:8633: checking how to hardcode library paths into programs > configure:8658: result: immediate > configure:8672: checking whether stripping libraries is possible > configure:8693: result: no > configure:9511: checking if libtool supports shared libraries > configure:9513: result: yes > configure:9516: checking whether to build shared libraries > configure:9537: result: yes > configure:9540: checking whether to build static libraries > configure:9544: result: yes > configure:9636: creating libtool > configure:10224: checking for ld used by g++ > configure:10291: result: /usr/ccs/bin/ld > configure:10300: checking if the linker (/usr/ccs/bin/ld) is GNU ld > configure:10315: result: no > configure:10366: checking whether the g++ linker (/usr/ccs/bin/ld) supports shared libraries > configure:11304: result: yes > configure:11322: g++ -c -g -O2 conftest.cpp >&5 > configure:11325: $? = 0 > configure:11444: checking for g++ option to produce PIC > configure:11718: result: -fPIC > configure:11726: checking if g++ PIC flag -fPIC works > configure:11744: g++ -c -g -O2 -fPIC -DPIC conftest.cpp >&5 > configure:11748: $? = 0 > configure:11761: result: yes > configure:11789: checking if g++ static flag -static works > configure:11817: result: no > configure:11827: checking if g++ supports -c -o file.o > configure:11848: g++ -c -g -O2 -o out/conftest2.o conftest.cpp >&5 > configure:11852: $? = 0 > configure:11874: result: yes > configure:11900: checking whether the g++ linker (/usr/ccs/bin/ld) supports shared libraries > configure:11925: result: yes > configure:11992: checking dynamic linker characteristics > configure:12601: result: solaris2.10 ld.so > configure:12610: checking how to hardcode library paths into programs > configure:12635: result: immediate > configure:13161: checking if libtool supports shared libraries > configure:13163: result: yes > configure:13166: checking whether to build shared libraries > configure:13186: result: yes > configure:13189: checking whether to build static libraries > configure:13193: result: yes > configure:13203: checking for g77 option to produce PIC > configure:13413: result: -fPIC > configure:13421: checking if g77 PIC flag -fPIC works > configure:13439: g77 -c -g -O2 -fPIC conftest.f >&5 > configure:13443: $? = 0 > configure:13456: result: yes > configure:13484: checking if g77 static flag -static works > configure:13512: result: no > configure:13522: checking if g77 supports -c -o file.o > configure:13543: g77 -c -g -O2 -o out/conftest2.o conftest.f >&5 > configure:13547: $? = 0 > configure:13569: result: yes > configure:13595: checking whether the g77 linker (/usr/ccs/bin/ld) supports shared libraries > configure:14533: result: yes > configure:14600: checking dynamic linker characteristics > configure:15209: result: solaris2.10 ld.so > configure:15218: checking how to hardcode library paths into programs > configure:15243: result: immediate > configure:18828: checking whether byte ordering is bigendian > configure:18855: gcc -c -O2 -D__EXTENSIONS__ conftest.c >&5 > conftest.c: In function `main': > conftest.c:32: error: `bogus' undeclared (first use in this function) > conftest.c:32: error: (Each undeclared identifier is reported only once > conftest.c:32: error: for each function it appears in.) > conftest.c:32: error: syntax error before "endian" > configure:18861: $? = 1 > configure: failed program was: > | /* confdefs.h. */ > | > | #define PACKAGE_NAME "" > | #define PACKAGE_TARNAME "" > | #define PACKAGE_VERSION "" > | #define PACKAGE_STRING "" > | #define PACKAGE_BUGREPORT "" > | #define PACKAGE "EMBOSS" > | #define VERSION "4.0.0" > | #define STDC_HEADERS 1 > | #define HAVE_SYS_TYPES_H 1 > | #define HAVE_SYS_STAT_H 1 > | #define HAVE_STDLIB_H 1 > | #define HAVE_STRING_H 1 > | #define HAVE_MEMORY_H 1 > | #define HAVE_STRINGS_H 1 > | #define HAVE_INTTYPES_H 1 > | #define HAVE_STDINT_H 1 > | #define HAVE_UNISTD_H 1 > | #define HAVE_DLFCN_H 1 > | #ifdef __cplusplus > | extern "C" void std::exit (int) throw (); using std::exit; > | #endif > | /* end confdefs.h. */ > | #include > | #include > | > | int > | main () > | { > | #if !BYTE_ORDER || !BIG_ENDIAN || !LITTLE_ENDIAN > | bogus endian macros > | #endif > | > | ; > | return 0; > | } > configure:19015: gcc -o conftest -O2 -D__EXTENSIONS__ conftest.c >&5 > configure:19018: $? = 0 > configure:19020: ./conftest > configure:19023: $? = 1 > configure: program exited with status 1 > configure: failed program was: > | /* confdefs.h. */ > | > | #define PACKAGE_NAME "" > | #define PACKAGE_TARNAME "" > | #define PACKAGE_VERSION "" > | #define PACKAGE_STRING "" > | #define PACKAGE_BUGREPORT "" > | #define PACKAGE "EMBOSS" > | #define VERSION "4.0.0" > | #define STDC_HEADERS 1 > | #define HAVE_SYS_TYPES_H 1 > | #define HAVE_SYS_STAT_H 1 > | #define HAVE_STDLIB_H 1 > | #define HAVE_STRING_H 1 > | #define HAVE_MEMORY_H 1 > | #define HAVE_STRINGS_H 1 > | #define HAVE_INTTYPES_H 1 > | #define HAVE_STDINT_H 1 > | #define HAVE_UNISTD_H 1 > | #define HAVE_DLFCN_H 1 > | #ifdef __cplusplus > | extern "C" void std::exit (int) throw (); using std::exit; > | #endif > | /* end confdefs.h. */ > | int > | main () > | { > | /* Are we little or big endian? From Harbison&Steele. */ > | union > | { > | long l; > | char c[sizeof (long)]; > | } u; > | u.l = 1; > | exit (u.c[sizeof (long) - 1] == 1); > | } > configure:19039: result: yes > configure:19089: checking for a BSD-compatible install > configure:19144: result: /local/bin/install -c > configure:19155: checking whether ln -s works > configure:19159: result: yes > configure:19166: checking whether make sets $(MAKE) > configure:19186: result: yes > configure:19236: checking for ranlib > configure:19263: result: ranlib > configure:19276: checking for X > configure:19381: gcc -E -DBENDIAN conftest.c > configure:19387: $? = 0 > configure:19437: gcc -o conftest -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c -lXt >&5 > Undefined first referenced > symbol in file > XrmInitialize /var/tmp//ccIjdzQL.o (symbol belongs to implicit dependency /usr/openwin/lib/libX11.so.4) > ld: fatal: Symbol referencing errors. No output written to conftest > collect2: ld returned 1 exit status > configure:19443: $? = 1 > configure: failed program was: > | /* confdefs.h. */ > | > | #define PACKAGE_NAME "" > | #define PACKAGE_TARNAME "" > | #define PACKAGE_VERSION "" > | #define PACKAGE_STRING "" > | #define PACKAGE_BUGREPORT "" > | #define PACKAGE "EMBOSS" > | #define VERSION "4.0.0" > | #define STDC_HEADERS 1 > | #define HAVE_SYS_TYPES_H 1 > | #define HAVE_SYS_STAT_H 1 > | #define HAVE_STDLIB_H 1 > | #define HAVE_STRING_H 1 > | #define HAVE_MEMORY_H 1 > | #define HAVE_STRINGS_H 1 > | #define HAVE_INTTYPES_H 1 > | #define HAVE_STDINT_H 1 > | #define HAVE_UNISTD_H 1 > | #define HAVE_DLFCN_H 1 > | #ifdef __cplusplus > | extern "C" void std::exit (int) throw (); using std::exit; > | #endif > | /* end confdefs.h. */ > | #include > | int > | main () > | { > | XrmInitialize () > | ; > | return 0; > | } > configure:19506: result: libraries /usr/lib, headers > configure:19530: checking whether -R must be followed by a space > configure:19549: gcc -o conftest -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c -R/usr/lib >&5 > configure:19555: $? = 0 > configure:19559: test -z > || test ! -s conftest.err > configure:19562: $? = 0 > configure:19565: test -s conftest > configure:19568: $? = 0 > configure:19580: result: no > configure:19678: gcc -o conftest -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c -L/usr/lib -R/usr/lib -lX11 >&5 > configure:19684: $? = 0 > configure:19688: test -z > || test ! -s conftest.err > configure:19691: $? = 0 > configure:19694: test -s conftest > configure:19697: $? = 0 > configure:19855: checking for gethostbyname > configure:19912: gcc -o conftest -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c >&5 > Undefined first referenced > symbol in file > gethostbyname /var/tmp//ccy7pKHR.o > ld: fatal: Symbol referencing errors. No output written to conftest > collect2: ld returned 1 exit status > configure:19918: $? = 1 > configure: failed program was: > | /* confdefs.h. */ > | > | #define PACKAGE_NAME "" > | #define PACKAGE_TARNAME "" > | #define PACKAGE_VERSION "" > | #define PACKAGE_STRING "" > | #define PACKAGE_BUGREPORT "" > | #define PACKAGE "EMBOSS" > | #define VERSION "4.0.0" > | #define STDC_HEADERS 1 > | #define HAVE_SYS_TYPES_H 1 > | #define HAVE_SYS_STAT_H 1 > | #define HAVE_STDLIB_H 1 > | #define HAVE_STRING_H 1 > | #define HAVE_MEMORY_H 1 > | #define HAVE_STRINGS_H 1 > | #define HAVE_INTTYPES_H 1 > | #define HAVE_STDINT_H 1 > | #define HAVE_UNISTD_H 1 > | #define HAVE_DLFCN_H 1 > | #ifdef __cplusplus > | extern "C" void std::exit (int) throw (); using std::exit; > | #endif > | /* end confdefs.h. */ > | /* Define gethostbyname to an innocuous variant, in case declares gethostbyname. > | For example, HP-UX 11i declares gettimeofday. */ > | #define gethostbyname innocuous_gethostbyname > | > | /* System header to define __stub macros and hopefully few prototypes, > | which can conflict with char gethostbyname (); below. > | Prefer to if __STDC__ is defined, since > | exists even on freestanding compilers. */ > | > | #ifdef __STDC__ > | # include > | #else > | # include > | #endif > | > | #undef gethostbyname > | > | /* Override any gcc2 internal prototype to avoid an error. */ > | #ifdef __cplusplus > | extern "C" > | { > | #endif > | /* We use char because int might match the return type of a gcc2 > | builtin and then its argument prototype would still apply. */ > | char gethostbyname (); > | /* The GNU C library defines this for functions which it implements > | to always fail with ENOSYS. Some functions are actually named > | something starting with __ and the normal name is an alias. */ > | #if defined (__stub_gethostbyname) || defined (__stub___gethostbyname) > | choke me > | #else > | char (*f) () = gethostbyname; > | #endif > | #ifdef __cplusplus > | } > | #endif > | > | int > | main () > | { > | return f != gethostbyname; > | ; > | return 0; > | } > configure:19943: result: no > configure:19947: checking for gethostbyname in -lnsl > configure:19977: gcc -o conftest -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c -lnsl >&5 > configure:19983: $? = 0 > configure:19987: test -z > || test ! -s conftest.err > configure:19990: $? = 0 > configure:19993: test -s conftest > configure:19996: $? = 0 > configure:20009: result: yes > configure:20094: checking for connect > configure:20151: gcc -o conftest -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c >&5 > Undefined first referenced > symbol in file > connect /var/tmp//cc2mi2rV.o > ld: fatal: Symbol referencing errors. No output written to conftest > collect2: ld returned 1 exit status > configure:20157: $? = 1 > configure: failed program was: > | /* confdefs.h. */ > | > | #define PACKAGE_NAME "" > | #define PACKAGE_TARNAME "" > | #define PACKAGE_VERSION "" > | #define PACKAGE_STRING "" > | #define PACKAGE_BUGREPORT "" > | #define PACKAGE "EMBOSS" > | #define VERSION "4.0.0" > | #define STDC_HEADERS 1 > | #define HAVE_SYS_TYPES_H 1 > | #define HAVE_SYS_STAT_H 1 > | #define HAVE_STDLIB_H 1 > | #define HAVE_STRING_H 1 > | #define HAVE_MEMORY_H 1 > | #define HAVE_STRINGS_H 1 > | #define HAVE_INTTYPES_H 1 > | #define HAVE_STDINT_H 1 > | #define HAVE_UNISTD_H 1 > | #define HAVE_DLFCN_H 1 > | #ifdef __cplusplus > | extern "C" void std::exit (int) throw (); using std::exit; > | #endif > | /* end confdefs.h. */ > | /* Define connect to an innocuous variant, in case declares connect. > | For example, HP-UX 11i declares gettimeofday. */ > | #define connect innocuous_connect > | > | /* System header to define __stub macros and hopefully few prototypes, > | which can conflict with char connect (); below. > | Prefer to if __STDC__ is defined, since > | exists even on freestanding compilers. */ > | > | #ifdef __STDC__ > | # include > | #else > | # include > | #endif > | > | #undef connect > | > | /* Override any gcc2 internal prototype to avoid an error. */ > | #ifdef __cplusplus > | extern "C" > | { > | #endif > | /* We use char because int might match the return type of a gcc2 > | builtin and then its argument prototype would still apply. */ > | char connect (); > | /* The GNU C library defines this for functions which it implements > | to always fail with ENOSYS. Some functions are actually named > | something starting with __ and the normal name is an alias. */ > | #if defined (__stub_connect) || defined (__stub___connect) > | choke me > | #else > | char (*f) () = connect; > | #endif > | #ifdef __cplusplus > | } > | #endif > | > | int > | main () > | { > | return f != connect; > | ; > | return 0; > | } > configure:20182: result: no > configure:20186: checking for connect in -lsocket > configure:20216: gcc -o conftest -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c -lsocket -lnsl >&5 > configure:20222: $? = 0 > configure:20226: test -z > || test ! -s conftest.err > configure:20229: $? = 0 > configure:20232: test -s conftest > configure:20235: $? = 0 > configure:20248: result: yes > configure:20257: checking for remove > configure:20314: gcc -o conftest -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c >&5 > configure:20320: $? = 0 > configure:20324: test -z > || test ! -s conftest.err > configure:20327: $? = 0 > configure:20330: test -s conftest > configure:20333: $? = 0 > configure:20345: result: yes > configure:20420: checking for shmat > configure:20477: gcc -o conftest -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c >&5 > configure:20483: $? = 0 > configure:20487: test -z > || test ! -s conftest.err > configure:20490: $? = 0 > configure:20493: test -s conftest > configure:20496: $? = 0 > configure:20508: result: yes > configure:20592: checking for IceConnectionNumber in -lICE > configure:20622: gcc -o conftest -O2 -D__EXTENSIONS__ -DBENDIAN -L/usr/lib conftest.c -lICE -lsocket -lnsl >&5 > configure:20628: $? = 0 > configure:20632: test -z > || test ! -s conftest.err > configure:20635: $? = 0 > configure:20638: test -s conftest > configure:20641: $? = 0 > configure:20654: result: yes > configure:20672: checking for dirent.h that defines DIR > configure:20696: gcc -c -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c >&5 > configure:20702: $? = 0 > configure:20706: test -z > || test ! -s conftest.err > configure:20709: $? = 0 > configure:20712: test -s conftest.o > configure:20715: $? = 0 > configure:20726: result: yes > configure:20739: checking for library containing opendir > configure:20769: gcc -o conftest -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c >&5 > configure:20775: $? = 0 > configure:20779: test -z > || test ! -s conftest.err > configure:20782: $? = 0 > configure:20785: test -s conftest > configure:20788: $? = 0 > configure:20858: result: none required > configure:20994: checking for ANSI C header files > configure:21150: result: yes > configure:21166: checking for unistd.h > configure:21171: result: yes > configure:21312: checking for an ANSI C-conforming const > configure:21379: gcc -c -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c >&5 > configure:21385: $? = 0 > configure:21389: test -z > || test ! -s conftest.err > configure:21392: $? = 0 > configure:21395: test -s conftest.o > configure:21398: $? = 0 > configure:21409: result: yes > configure:21419: checking for pid_t > configure:21443: gcc -c -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c >&5 > configure:21449: $? = 0 > configure:21453: test -z > || test ! -s conftest.err > configure:21456: $? = 0 > configure:21459: test -s conftest.o > configure:21462: $? = 0 > configure:21473: result: yes > configure:21485: checking for size_t > configure:21509: gcc -c -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c >&5 > configure:21515: $? = 0 > configure:21519: test -z > || test ! -s conftest.err > configure:21522: $? = 0 > configure:21525: test -s conftest.o > configure:21528: $? = 0 > configure:21539: result: yes > configure:21551: checking whether struct tm is in sys/time.h or time.h > configure:21574: gcc -c -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c >&5 > configure:21580: $? = 0 > configure:21584: test -z > || test ! -s conftest.err > configure:21587: $? = 0 > configure:21590: test -s conftest.o > configure:21593: $? = 0 > configure:21604: result: time.h > configure:21615: checking whether getpgrp requires zero arguments > configure:21637: gcc -c -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c >&5 > conftest.c: In function `main': > conftest.c:65: error: too many arguments to function `getpgrp' > configure:21643: $? = 1 > configure: failed program was: > | /* confdefs.h. */ > | > | #define PACKAGE_NAME "" > | #define PACKAGE_TARNAME "" > | #define PACKAGE_VERSION "" > | #define PACKAGE_STRING "" > | #define PACKAGE_BUGREPORT "" > | #define PACKAGE "EMBOSS" > | #define VERSION "4.0.0" > | #define STDC_HEADERS 1 > | #define HAVE_SYS_TYPES_H 1 > | #define HAVE_SYS_STAT_H 1 > | #define HAVE_STDLIB_H 1 > | #define HAVE_STRING_H 1 > | #define HAVE_MEMORY_H 1 > | #define HAVE_STRINGS_H 1 > | #define HAVE_INTTYPES_H 1 > | #define HAVE_STDINT_H 1 > | #define HAVE_UNISTD_H 1 > | #define HAVE_DLFCN_H 1 > | #ifdef __cplusplus > | extern "C" void std::exit (int) throw (); using std::exit; > | #endif > | #define HAVE_DIRENT_H 1 > | #define STDC_HEADERS 1 > | #define HAVE_UNISTD_H 1 > | /* end confdefs.h. */ > | #include > | #if HAVE_SYS_TYPES_H > | # include > | #endif > | #if HAVE_SYS_STAT_H > | # include > | #endif > | #if STDC_HEADERS > | # include > | # include > | #else > | # if HAVE_STDLIB_H > | # include > | # endif > | #endif > | #if HAVE_STRING_H > | # if !STDC_HEADERS && HAVE_MEMORY_H > | # include > | # endif > | # include > | #endif > | #if HAVE_STRINGS_H > | # include > | #endif > | #if HAVE_INTTYPES_H > | # include > | #else > | # if HAVE_STDINT_H > | # include > | # endif > | #endif > | #if HAVE_UNISTD_H > | # include > | #endif > | int > | main () > | { > | getpgrp (0); > | ; > | return 0; > | } > configure:21668: result: yes > configure:21682: checking for strftime > configure:21739: gcc -o conftest -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c >&5 > conftest.c:53: warning: conflicting types for built-in function 'strftime' > configure:21745: $? = 0 > configure:21749: test -z > || test ! -s conftest.err > configure:21752: $? = 0 > configure:21755: test -s conftest > configure:21758: $? = 0 > configure:21770: result: yes > configure:21860: checking for unistd.h > configure:21865: result: yes > configure:21869: checking vfork.h usability > configure:21881: gcc -c -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c >&5 > conftest.c:65:19: vfork.h: No such file or directory > configure:21887: $? = 1 > configure: failed program was: > | /* confdefs.h. */ > | > | #define PACKAGE_NAME "" > | #define PACKAGE_TARNAME "" > | #define PACKAGE_VERSION "" > | #define PACKAGE_STRING "" > | #define PACKAGE_BUGREPORT "" > | #define PACKAGE "EMBOSS" > | #define VERSION "4.0.0" > | #define STDC_HEADERS 1 > | #define HAVE_SYS_TYPES_H 1 > | #define HAVE_SYS_STAT_H 1 > | #define HAVE_STDLIB_H 1 > | #define HAVE_STRING_H 1 > | #define HAVE_MEMORY_H 1 > | #define HAVE_STRINGS_H 1 > | #define HAVE_INTTYPES_H 1 > | #define HAVE_STDINT_H 1 > | #define HAVE_UNISTD_H 1 > | #define HAVE_DLFCN_H 1 > | #ifdef __cplusplus > | extern "C" void std::exit (int) throw (); using std::exit; > | #endif > | #define HAVE_DIRENT_H 1 > | #define STDC_HEADERS 1 > | #define HAVE_UNISTD_H 1 > | #define GETPGRP_VOID 1 > | #define HAVE_STRFTIME 1 > | #define HAVE_UNISTD_H 1 > | /* end confdefs.h. */ > | #include > | #if HAVE_SYS_TYPES_H > | # include > | #endif > | #if HAVE_SYS_STAT_H > | # include > | #endif > | #if STDC_HEADERS > | # include > | # include > | #else > | # if HAVE_STDLIB_H > | # include > | # endif > | #endif > | #if HAVE_STRING_H > | # if !STDC_HEADERS && HAVE_MEMORY_H > | # include > | # endif > | # include > | #endif > | #if HAVE_STRINGS_H > | # include > | #endif > | #if HAVE_INTTYPES_H > | # include > | #else > | # if HAVE_STDINT_H > | # include > | # endif > | #endif > | #if HAVE_UNISTD_H > | # include > | #endif > | #include > configure:21910: result: no > configure:21914: checking vfork.h presence > configure:21924: gcc -E -DBENDIAN conftest.c > conftest.c:31:19: vfork.h: No such file or directory > configure:21930: $? = 1 > configure: failed program was: > | /* confdefs.h. */ > | > | #define PACKAGE_NAME "" > | #define PACKAGE_TARNAME "" > | #define PACKAGE_VERSION "" > | #define PACKAGE_STRING "" > | #define PACKAGE_BUGREPORT "" > | #define PACKAGE "EMBOSS" > | #define VERSION "4.0.0" > | #define STDC_HEADERS 1 > | #define HAVE_SYS_TYPES_H 1 > | #define HAVE_SYS_STAT_H 1 > | #define HAVE_STDLIB_H 1 > | #define HAVE_STRING_H 1 > | #define HAVE_MEMORY_H 1 > | #define HAVE_STRINGS_H 1 > | #define HAVE_INTTYPES_H 1 > | #define HAVE_STDINT_H 1 > | #define HAVE_UNISTD_H 1 > | #define HAVE_DLFCN_H 1 > | #ifdef __cplusplus > | extern "C" void std::exit (int) throw (); using std::exit; > | #endif > | #define HAVE_DIRENT_H 1 > | #define STDC_HEADERS 1 > | #define HAVE_UNISTD_H 1 > | #define GETPGRP_VOID 1 > | #define HAVE_STRFTIME 1 > | #define HAVE_UNISTD_H 1 > | /* end confdefs.h. */ > | #include > configure:21950: result: no > configure:21985: checking for vfork.h > configure:21992: result: no > configure:22010: checking for fork > configure:22067: gcc -o conftest -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c >&5 > configure:22073: $? = 0 > configure:22077: test -z > || test ! -s conftest.err > configure:22080: $? = 0 > configure:22083: test -s conftest > configure:22086: $? = 0 > configure:22098: result: yes > configure:22010: checking for vfork > configure:22067: gcc -o conftest -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c >&5 > configure:22073: $? = 0 > configure:22077: test -z > || test ! -s conftest.err > configure:22080: $? = 0 > configure:22083: test -s conftest > configure:22086: $? = 0 > configure:22098: result: yes > configure:22109: checking for working fork > configure:22132: gcc -o conftest -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c >&5 > configure:22135: $? = 0 > configure:22137: ./conftest > configure:22140: $? = 0 > configure:22154: result: yes > configure:22175: checking for working vfork > configure:22308: result: yes > configure:22343: checking for vprintf > configure:22400: gcc -o conftest -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c >&5 > conftest.c:59: warning: conflicting types for built-in function 'vprintf' > configure:22406: $? = 0 > configure:22410: test -z > || test ! -s conftest.err > configure:22413: $? = 0 > configure:22416: test -s conftest > configure:22419: $? = 0 > configure:22431: result: yes > configure:22438: checking for _doprnt > configure:22495: gcc -o conftest -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c >&5 > configure:22501: $? = 0 > configure:22505: test -z > || test ! -s conftest.err > configure:22508: $? = 0 > configure:22511: test -s conftest > configure:22514: $? = 0 > configure:22526: result: yes > configure:22545: checking for memmove > configure:22602: gcc -o conftest -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c >&5 > conftest.c:61: warning: conflicting types for built-in function 'memmove' > configure:22608: $? = 0 > configure:22612: test -z > || test ! -s conftest.err > configure:22615: $? = 0 > configure:22618: test -s conftest > configure:22621: $? = 0 > configure:22633: result: yes > configure:22652: checking for gethostbyname in -lc > configure:22682: gcc -o conftest -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c -lc >&5 > Undefined first referenced > symbol in file > gethostbyname /var/tmp//ccSBeEVg.o > ld: fatal: Symbol referencing errors. No output written to conftest > collect2: ld returned 1 exit status > configure:22688: $? = 1 > configure: failed program was: > | /* confdefs.h. */ > | > | #define PACKAGE_NAME "" > | #define PACKAGE_TARNAME "" > | #define PACKAGE_VERSION "" > | #define PACKAGE_STRING "" > | #define PACKAGE_BUGREPORT "" > | #define PACKAGE "EMBOSS" > | #define VERSION "4.0.0" > | #define STDC_HEADERS 1 > | #define HAVE_SYS_TYPES_H 1 > | #define HAVE_SYS_STAT_H 1 > | #define HAVE_STDLIB_H 1 > | #define HAVE_STRING_H 1 > | #define HAVE_MEMORY_H 1 > | #define HAVE_STRINGS_H 1 > | #define HAVE_INTTYPES_H 1 > | #define HAVE_STDINT_H 1 > | #define HAVE_UNISTD_H 1 > | #define HAVE_DLFCN_H 1 > | #ifdef __cplusplus > | extern "C" void std::exit (int) throw (); using std::exit; > | #endif > | #define HAVE_DIRENT_H 1 > | #define STDC_HEADERS 1 > | #define HAVE_UNISTD_H 1 > | #define GETPGRP_VOID 1 > | #define HAVE_STRFTIME 1 > | #define HAVE_UNISTD_H 1 > | #define HAVE_FORK 1 > | #define HAVE_VFORK 1 > | #define HAVE_WORKING_VFORK 1 > | #define HAVE_WORKING_FORK 1 > | #define HAVE_VPRINTF 1 > | #define HAVE_DOPRNT 1 > | #define HAVE_MEMMOVE 1 > | /* end confdefs.h. */ > | > | /* Override any gcc2 internal prototype to avoid an error. */ > | #ifdef __cplusplus > | extern "C" > | #endif > | /* We use char because int might match the return type of a gcc2 > | builtin and then its argument prototype would still apply. */ > | char gethostbyname (); > | int > | main () > | { > | gethostbyname (); > | ; > | return 0; > | } > configure:22714: result: no > configure:22722: checking for socket in -lc > configure:22752: gcc -o conftest -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c -lc -lnsl >&5 > Undefined first referenced > symbol in file > socket /var/tmp//cc6qIEXF.o > ld: fatal: Symbol referencing errors. No output written to conftest > collect2: ld returned 1 exit status > configure:22758: $? = 1 > configure: failed program was: > | /* confdefs.h. */ > | > | #define PACKAGE_NAME "" > | #define PACKAGE_TARNAME "" > | #define PACKAGE_VERSION "" > | #define PACKAGE_STRING "" > | #define PACKAGE_BUGREPORT "" > | #define PACKAGE "EMBOSS" > | #define VERSION "4.0.0" > | #define STDC_HEADERS 1 > | #define HAVE_SYS_TYPES_H 1 > | #define HAVE_SYS_STAT_H 1 > | #define HAVE_STDLIB_H 1 > | #define HAVE_STRING_H 1 > | #define HAVE_MEMORY_H 1 > | #define HAVE_STRINGS_H 1 > | #define HAVE_INTTYPES_H 1 > | #define HAVE_STDINT_H 1 > | #define HAVE_UNISTD_H 1 > | #define HAVE_DLFCN_H 1 > | #ifdef __cplusplus > | extern "C" void std::exit (int) throw (); using std::exit; > | #endif > | #define HAVE_DIRENT_H 1 > | #define STDC_HEADERS 1 > | #define HAVE_UNISTD_H 1 > | #define GETPGRP_VOID 1 > | #define HAVE_STRFTIME 1 > | #define HAVE_UNISTD_H 1 > | #define HAVE_FORK 1 > | #define HAVE_VFORK 1 > | #define HAVE_WORKING_VFORK 1 > | #define HAVE_WORKING_FORK 1 > | #define HAVE_VPRINTF 1 > | #define HAVE_DOPRNT 1 > | #define HAVE_MEMMOVE 1 > | /* end confdefs.h. */ > | > | /* Override any gcc2 internal prototype to avoid an error. */ > | #ifdef __cplusplus > | extern "C" > | #endif > | /* We use char because int might match the return type of a gcc2 > | builtin and then its argument prototype would still apply. */ > | char socket (); > | int > | main () > | { > | socket (); > | ; > | return 0; > | } > configure:22784: result: no > configure:22793: checking for main in -lm > configure:22817: gcc -o conftest -O2 -D__EXTENSIONS__ -DBENDIAN conftest.c -lm -lnsl -lsocket >&5 > configure:22823: $? = 0 > configure:22827: test -z > || test ! -s conftest.err > configure:22830: $? = 0 > configure:22833: test -s conftest > configure:22836: $? = 0 > configure:22849: result: yes > configure:22942: checking if docroot is given > configure:22955: result: no > configure:22963: checking if gcc profiling is selected > configure:22977: result: no > configure:22987: checking if java include directory given > configure:23057: result: no > configure:23072: checking if java OS include directory given > configure:23094: result: no > configure:23113: checking if png driver is wanted > configure:23120: result: yes > configure:23156: checking for libiconv_close in -liconv > configure:23186: gcc -o conftest -O2 -D__EXTENSIONS__ -DBENDIAN -I/local/include -L/local/lib conftest.c -liconv -L/local/lib -liconv -lm -lnsl -lsocket >&5 > configure:23192: $? = 0 > configure:23196: test -z > || test ! -s conftest.err > configure:23199: $? = 0 > configure:23202: test -s conftest > configure:23205: $? = 0 > configure:23218: result: yes > configure:23239: checking for inflateEnd in -lz > configure:23269: gcc -o conftest -O2 -D__EXTENSIONS__ -DBENDIAN -I/local/include -L/local/lib -L/local/lib -liconv -R/local/lib conftest.c -lz -L/local/lib -lz -lm -lnsl -lsocket >&5 > configure:23275: $? = 0 > configure:23279: test -z > || test ! -s conftest.err > configure:23282: $? = 0 > configure:23285: test -s conftest > configure:23288: $? = 0 > configure:23301: result: yes > configure:23315: checking for png_destroy_read_struct in -lpng > configure:23345: gcc -o conftest -O2 -D__EXTENSIONS__ -DBENDIAN -I/local/include -L/local/lib -L/local/lib -liconv -R/local/lib conftest.c -lpng -L/local/lib -lz -lm -lnsl -lsocket >&5 > configure:23351: $? = 0 > configure:23355: test -z > || test ! -s conftest.err > configure:23358: $? = 0 > configure:23361: test -s conftest > configure:23364: $? = 0 > configure:23377: result: yes > configure:23394: checking for gdImageCreateFromPng in -lgd > configure:23424: gcc -o conftest -O2 -D__EXTENSIONS__ -DBENDIAN -I/local/include -L/local/lib -L/local/lib -liconv -R/local/lib conftest.c -lgd -L/local/lib -lgd -lpng -lz -lm -lm -lnsl -lsocket >&5 > configure:23430: $? = 0 > configure:23434: test -z > || test ! -s conftest.err > configure:23437: $? = 0 > configure:23440: test -s conftest > configure:23443: $? = 0 > configure:23456: result: yes > configure:23536: checking if any authorisation type is given > configure:23708: result: no > configure:23729: checking for gdome2 > configure:23747: result: no > configure:23756: checking if Linux x86_64 > configure:23770: result: no > configure:23831: checking for large file support > configure:23866: result: done > configure:23883: checking for purify > configure:23897: result: no > configure:24011: checking if any threading type is given > configure:24077: result: no > configure:24288: creating ./config.status > > ## ---------------------- ## > ## Running config.status. ## > ## ---------------------- ## > > This file was extended by config.status, which was > generated by GNU Autoconf 2.59. Invocation command line was > > CONFIG_FILES = > CONFIG_HEADERS = > CONFIG_LINKS = > CONFIG_COMMANDS = > $ ./config.status > > on helix > > config.status:801: creating plplot/Makefile > config.status:801: creating plplot/lib/Makefile > config.status:801: creating nucleus/Makefile > config.status:801: creating ajax/Makefile > config.status:801: creating emboss/Makefile > config.status:801: creating emboss/acd/Makefile > config.status:801: creating test/Makefile > config.status:801: creating test/data/Makefile > config.status:801: creating test/embl/Makefile > config.status:801: creating test/genbank/Makefile > config.status:801: creating test/gb/Makefile > config.status:801: creating test/pir/Makefile > config.status:801: creating test/swiss/Makefile > config.status:801: creating test/swnew/Makefile > config.status:801: creating test/wormpep/Makefile > config.status:801: creating emboss/data/Makefile > config.status:801: creating emboss/data/AAINDEX/Makefile > config.status:801: creating emboss/data/CODONS/Makefile > config.status:801: creating emboss/data/REBASE/Makefile > config.status:801: creating emboss/data/PRINTS/Makefile > config.status:801: creating emboss/data/PROSITE/Makefile > config.status:801: creating doc/Makefile > config.status:801: creating doc/manuals/Makefile > config.status:801: creating doc/tutorials/Makefile > config.status:801: creating doc/programs/Makefile > config.status:801: creating doc/programs/html/Makefile > config.status:801: creating doc/programs/text/Makefile > config.status:801: creating jemboss/Makefile > config.status:801: creating jemboss/api/Makefile > config.status:801: creating jemboss/api/org/Makefile > config.status:801: creating jemboss/api/org/emboss/Makefile > config.status:801: creating jemboss/api/org/emboss/jemboss/Makefile > config.status:801: creating jemboss/api/org/emboss/jemboss/gui/Makefile > config.status:801: creating jemboss/api/org/emboss/jemboss/gui/filetree/Makefile > config.status:801: creating jemboss/api/org/emboss/jemboss/gui/form/Makefile > config.status:801: creating jemboss/api/org/emboss/jemboss/gui/sequenceChooser/Makefile > config.status:801: creating jemboss/api/org/emboss/jemboss/gui/startup/Makefile > config.status:801: creating jemboss/api/org/emboss/jemboss/parser/Makefile > config.status:801: creating jemboss/api/org/emboss/jemboss/parser/acd/Makefile > config.status:801: creating jemboss/api/org/emboss/jemboss/programs/Makefile > config.status:801: creating jemboss/api/org/emboss/jemboss/soap/Makefile > config.status:801: creating jemboss/images/Makefile > config.status:801: creating jemboss/lib/Makefile > config.status:801: creating jemboss/lib/axis/Makefile > config.status:801: creating jemboss/org/Makefile > config.status:801: creating jemboss/org/emboss/Makefile > config.status:801: creating jemboss/org/emboss/jemboss/Makefile > config.status:801: creating jemboss/org/emboss/jemboss/graphics/Makefile > config.status:801: creating jemboss/org/emboss/jemboss/gui/Makefile > config.status:801: creating jemboss/org/emboss/jemboss/gui/filetree/Makefile > config.status:801: creating jemboss/org/emboss/jemboss/gui/form/Makefile > config.status:801: creating jemboss/org/emboss/jemboss/gui/startup/Makefile > config.status:801: creating jemboss/org/emboss/jemboss/gui/sequenceChooser/Makefile > config.status:801: creating jemboss/org/emboss/jemboss/parser/Makefile > config.status:801: creating jemboss/org/emboss/jemboss/parser/acd/Makefile > config.status:801: creating jemboss/org/emboss/jemboss/programs/Makefile > config.status:801: creating jemboss/org/emboss/jemboss/server/Makefile > config.status:801: creating jemboss/org/emboss/jemboss/soap/Makefile > config.status:801: creating jemboss/org/emboss/jemboss/editor/Makefile > config.status:801: creating jemboss/org/emboss/jemboss/draw/Makefile > config.status:801: creating jemboss/resources/Makefile > config.status:801: creating jemboss/utils/Makefile > config.status:801: creating Makefile > config.status:984: executing depfiles commands > > ## ---------------- ## > ## Cache variables. ## > ## ---------------- ## > > ac_cv_build=sparc-sun-solaris2.10 > ac_cv_build_alias=sparc-sun-solaris2.10 > ac_cv_c_bigendian=yes > ac_cv_c_compiler_gnu=yes > ac_cv_c_const=yes > ac_cv_cxx_compiler_gnu=yes > ac_cv_env_CC_set= > ac_cv_env_CC_value= > ac_cv_env_CFLAGS_set= > ac_cv_env_CFLAGS_value= > ac_cv_env_CPPFLAGS_set= > ac_cv_env_CPPFLAGS_value= > ac_cv_env_CPP_set= > ac_cv_env_CPP_value= > ac_cv_env_CXXCPP_set= > ac_cv_env_CXXCPP_value= > ac_cv_env_CXXFLAGS_set= > ac_cv_env_CXXFLAGS_value= > ac_cv_env_CXX_set= > ac_cv_env_CXX_value= > ac_cv_env_F77_set= > ac_cv_env_F77_value= > ac_cv_env_FFLAGS_set= > ac_cv_env_FFLAGS_value= > ac_cv_env_LDFLAGS_set= > ac_cv_env_LDFLAGS_value= > ac_cv_env_build_alias_set= > ac_cv_env_build_alias_value= > ac_cv_env_host_alias_set= > ac_cv_env_host_alias_value= > ac_cv_env_target_alias_set= > ac_cv_env_target_alias_value= > ac_cv_exeext= > ac_cv_f77_compiler_gnu=yes > ac_cv_func__doprnt=yes > ac_cv_func_connect=no > ac_cv_func_fork=yes > ac_cv_func_fork_works=yes > ac_cv_func_gethostbyname=no > ac_cv_func_getpgrp_void=yes > ac_cv_func_memmove=yes > ac_cv_func_remove=yes > ac_cv_func_shmat=yes > ac_cv_func_strftime=yes > ac_cv_func_vfork=yes > ac_cv_func_vfork_works=yes > ac_cv_func_vprintf=yes > ac_cv_have_x='have_x=yes ac_x_includes= ac_x_libraries=/usr/lib' > ac_cv_header_dirent_dirent_h=yes > ac_cv_header_dlfcn_h=yes > ac_cv_header_inttypes_h=yes > ac_cv_header_memory_h=yes > ac_cv_header_stdc=yes > ac_cv_header_stdint_h=yes > ac_cv_header_stdlib_h=yes > ac_cv_header_string_h=yes > ac_cv_header_strings_h=yes > ac_cv_header_sys_stat_h=yes > ac_cv_header_sys_types_h=yes > ac_cv_header_unistd_h=yes > ac_cv_header_vfork_h=no > ac_cv_host=sparc-sun-solaris2.10 > ac_cv_host_alias=sparc-sun-solaris2.10 > ac_cv_lib_ICE_IceConnectionNumber=yes > ac_cv_lib_c_gethostbyname=no > ac_cv_lib_c_socket=no > ac_cv_lib_gd_gdImageCreateFromPng=yes > ac_cv_lib_iconv_libiconv_close=yes > ac_cv_lib_m_main=yes > ac_cv_lib_nsl_gethostbyname=yes > ac_cv_lib_png_png_destroy_read_struct=yes > ac_cv_lib_socket_connect=yes > ac_cv_lib_z_inflateEnd=yes > ac_cv_objext=o > ac_cv_path_install='/local/bin/install -c' > ac_cv_prog_AWK=gawk > ac_cv_prog_CPP='gcc -E' > ac_cv_prog_CXXCPP='g++ -E' > ac_cv_prog_ac_ct_AR=ar > ac_cv_prog_ac_ct_CC=gcc > ac_cv_prog_ac_ct_CXX=g++ > ac_cv_prog_ac_ct_F77=g77 > ac_cv_prog_ac_ct_RANLIB=ranlib > ac_cv_prog_ac_ct_STRIP=strip > ac_cv_prog_cc_g=yes > ac_cv_prog_cc_stdc= > ac_cv_prog_cxx_g=yes > ac_cv_prog_egrep='grep -E' > ac_cv_prog_f77_g=yes > ac_cv_prog_make_make_set=yes > ac_cv_search_opendir='none required' > ac_cv_struct_tm=time.h > ac_cv_type_pid_t=yes > ac_cv_type_size_t=yes > am_cv_CC_dependencies_compiler_type=gcc3 > am_cv_CXX_dependencies_compiler_type=gcc3 > lt_cv_deplibs_check_method=pass_all > lt_cv_file_magic_cmd='$MAGIC_CMD' > lt_cv_file_magic_test_file= > lt_cv_ld_reload_flag=-r > lt_cv_objdir=.libs > lt_cv_path_LD=/usr/ccs/bin/ld > lt_cv_path_LDCXX=/usr/ccs/bin/ld > lt_cv_path_NM='/usr/ccs/bin/nm -p' > lt_cv_path_SED=/local/bin/sed > lt_cv_prog_compiler_c_o=yes > lt_cv_prog_compiler_c_o_CXX=yes > lt_cv_prog_compiler_c_o_F77=yes > lt_cv_prog_compiler_rtti_exceptions=no > lt_cv_prog_gnu_ld=no > lt_cv_prog_gnu_ldcxx=no > lt_cv_sys_global_symbol_pipe='sed -n -e '\''s/^.*[ ]\([BDRT][BDRT]*\)[ ][ ]*\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2 \2/p'\''' > lt_cv_sys_global_symbol_to_c_name_address='sed -n -e '\''s/^: \([^ ]*\) $/ {\"\1\", (lt_ptr) 0},/p'\'' -e '\''s/^[BCDEGRST] \([^ ]*\) \([^ ]*\)$/ {"\2", (lt_ptr) \&\2},/p'\''' > lt_cv_sys_global_symbol_to_cdecl='sed -n -e '\''s/^. .* \(.*\)$/extern int \1;/p'\''' > lt_cv_sys_max_cmd_len=262144 > lt_lt_cv_prog_compiler_c_o='"yes"' > lt_lt_cv_prog_compiler_c_o_CXX='"yes"' > lt_lt_cv_prog_compiler_c_o_F77='"yes"' > lt_lt_cv_sys_global_symbol_pipe='"sed -n -e '\''s/^.*[ ]\\([BDRT][BDRT]*\\)[ ][ ]*\\([_A-Za-z][_A-Za-z0-9]*\\)\$/\\1 \\2 \\2/p'\''"' > lt_lt_cv_sys_global_symbol_to_c_name_address='"sed -n -e '\''s/^: \\([^ ]*\\) \$/ {\\\"\\1\\\", (lt_ptr) 0},/p'\'' -e '\''s/^[BCDEGRST] \\([^ ]*\\) \\([^ ]*\\)\$/ {\"\\2\", (lt_ptr) \\&\\2},/p'\''"' > lt_lt_cv_sys_global_symbol_to_cdecl='"sed -n -e '\''s/^. .* \\(.*\\)\$/extern int \\1;/p'\''"' > > ## ----------------- ## > ## Output variables. ## > ## ----------------- ## > > ACLOCAL='${SHELL} /bioportal/build/EMBOSS-4.0.0/missing --run aclocal-1.9' > AJAX_FIXED_ROOT='\"/bioportal/build/EMBOSS-4.0.0/emboss\"' > AMDEPBACKSLASH='\' > AMDEP_FALSE='#' > AMDEP_TRUE='' > AMPNG_FALSE='#' > AMPNG_TRUE='' > AMTAR='${SHELL} /bioportal/build/EMBOSS-4.0.0/missing --run tar' > AR='ar' > AUTOCONF='${SHELL} /bioportal/build/EMBOSS-4.0.0/missing --run autoconf' > AUTOHEADER='${SHELL} /bioportal/build/EMBOSS-4.0.0/missing --run autoheader' > AUTOMAKE='${SHELL} /bioportal/build/EMBOSS-4.0.0/missing --run automake-1.9' > AWK='gawk' > CC='gcc' > CCDEPMODE='depmode=gcc3' > CFLAGS=' -O2 -D__EXTENSIONS__' > CPP='gcc -E' > CPPFLAGS='-DAJ_SolarisLF -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -DBENDIAN -I/local/include -DNO_AUTH' > CXX='g++' > CXXCPP='g++ -E' > CXXDEPMODE='depmode=gcc3' > CXXFLAGS='-g -O2 ' > CYGPATH_W='echo' > DEFS='-DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"EMBOSS\" -DVERSION=\"4.0.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_DIRENT_H=1 -DSTDC_HEADERS=1 -DHAVE_UNISTD_H=1 -DGETPGRP_VOID=1 -DHAVE_STRFTIME=1 -DHAVE_UNISTD_H=1 -DHAVE_FORK=1 -DHAVE_VFORK=1 -DHAVE_WORKING_VFORK=1 -DHAVE_WORKING_FORK=1 -DHAVE_VPRINTF=1 -DHAVE_DOPRNT=1 -DHAVE_MEMMOVE=1 -DHAVE_LIBM=1 -DPLD_png=1 ' > DEPDIR='.deps' > ECHO='echo' > ECHO_C='' > ECHO_N='-n' > ECHO_T='' > EGREP='grep -E' > EMBOSS_TOP='/bioportal/build/EMBOSS-4.0.0' > EXEEXT='' > F77='g77' > FFLAGS='-g -O2' > HAVE_MEMMOVE='' > HAVE_STRERROR='' > INSTALL_DATA='${INSTALL} -m 644' > INSTALL_PROGRAM='${INSTALL}' > INSTALL_SCRIPT='${INSTALL}' > INSTALL_STRIP_PROGRAM='${SHELL} $(install_sh) -c -s' > ISAIXIA64='' > ISAIXIA64_FALSE='' > ISAIXIA64_TRUE='#' > ISCYGWIN='' > ISCYGWIN_FALSE='' > ISCYGWIN_TRUE='#' > ISSHARED_FALSE='#' > ISSHARED_TRUE='' > JAVA_OK='' > LDFLAGS=' -L/local/lib -L/local/lib -liconv -R/local/lib -R/local/lib' > LIBOBJS='' > LIBS='-lm -lnsl -lsocket -lgd -lpng -lz -lm -liconv' > LIBTOOL='$(SHELL) $(top_builddir)/libtool' > LN_S='ln -s' > LTLIBOBJS='' > MAKEINFO='${SHELL} /bioportal/build/EMBOSS-4.0.0/missing --run makeinfo' > NEEDAJAX='' > NEEDAJAX_FALSE='' > NEEDAJAX_TRUE='#' > OBJEXT='o' > PACKAGE='EMBOSS' > PACKAGE_BUGREPORT='' > PACKAGE_NAME='' > PACKAGE_STRING='' > PACKAGE_TARNAME='' > PACKAGE_VERSION='' > PATH_SEPARATOR=':' > PCRE_DATE='21-May-2003' > PCRE_LIB_VERSION='0:1:0' > PCRE_MAJOR='4' > PCRE_MINOR='3' > PCRE_POSIXLIB_VERSION='0:0:0' > PCRE_VERSION='4.3' > POSIX_MALLOC_THRESHOLD='-DPOSIX_MALLOC_THRESHOLD=10' > PURIFY_FALSE='' > PURIFY_TRUE='#' > RANLIB='ranlib' > SET_MAKE='' > SHELL='/bin/bash' > STRIP='strip' > VERSION='4.0.0' > XLIB=' -L/usr/lib -R/usr/lib -lX11 -lsocket -lnsl' > X_CFLAGS='' > X_EXTRA_LIBS='-lsocket -lnsl' > X_LIBS=' -L/usr/lib -R/usr/lib' > X_PRE_LIBS=' -lSM -lICE' > ac_ct_AR='ar' > ac_ct_CC='gcc' > ac_ct_CXX='g++' > ac_ct_F77='g77' > ac_ct_RANLIB='ranlib' > ac_ct_STRIP='strip' > am__fastdepCC_FALSE='#' > am__fastdepCC_TRUE='' > am__fastdepCXX_FALSE='#' > am__fastdepCXX_TRUE='' > am__include='include' > am__leading_dot='.' > am__quote='' > am__tar='${AMTAR} chof - "$$tardir"' > am__untar='${AMTAR} xf -' > bindir='${exec_prefix}/bin' > build='sparc-sun-solaris2.10' > build_alias='' > build_cpu='sparc' > build_os='solaris2.10' > build_vendor='sun' > datadir='${prefix}/share' > exec_prefix='${prefix}' > havejavac='' > host='sparc-sun-solaris2.10' > host_alias='' > host_cpu='sparc' > host_os='solaris2.10' > host_vendor='sun' > includedir='${prefix}/include' > infodir='${prefix}/info' > install_sh='/bioportal/build/EMBOSS-4.0.0/install-sh' > libdir='${exec_prefix}/lib' > libexecdir='${exec_prefix}/libexec' > localstatedir='${prefix}/var' > mandir='${prefix}/man' > mkdir_p='mkdir -p --' > oldincludedir='/usr/include' > prefix='/bioportal/sw/encap/emboss-4.0.0' > program_transform_name='s,x,x,' > sbindir='${exec_prefix}/sbin' > sharedstatedir='${prefix}/com' > sysconfdir='${prefix}/etc' > target_alias='' > > ## ----------- ## > ## confdefs.h. ## > ## ----------- ## > > #define GETPGRP_VOID 1 > #define HAVE_DIRENT_H 1 > #define HAVE_DLFCN_H 1 > #define HAVE_DOPRNT 1 > #define HAVE_FORK 1 > #define HAVE_INTTYPES_H 1 > #define HAVE_LIBM 1 > #define HAVE_MEMMOVE 1 > #define HAVE_MEMORY_H 1 > #define HAVE_STDINT_H 1 > #define HAVE_STDLIB_H 1 > #define HAVE_STRFTIME 1 > #define HAVE_STRINGS_H 1 > #define HAVE_STRING_H 1 > #define HAVE_SYS_STAT_H 1 > #define HAVE_SYS_TYPES_H 1 > #define HAVE_UNISTD_H 1 > #define HAVE_UNISTD_H 1 > #define HAVE_UNISTD_H 1 > #define HAVE_VFORK 1 > #define HAVE_VPRINTF 1 > #define HAVE_WORKING_FORK 1 > #define HAVE_WORKING_VFORK 1 > #define PACKAGE "EMBOSS" > #define PACKAGE_BUGREPORT "" > #define PACKAGE_NAME "" > #define PACKAGE_STRING "" > #define PACKAGE_TARNAME "" > #define PACKAGE_VERSION "" > #define PLD_png 1 > #define STDC_HEADERS 1 > #define STDC_HEADERS 1 > #define VERSION "4.0.0" > #endif > #ifdef __cplusplus > extern "C" void std::exit (int) throw (); using std::exit; > > configure: exit 0 > From gbottu at ben.vub.ac.be Fri Nov 3 08:43:31 2006 From: gbottu at ben.vub.ac.be (Guy Bottu) Date: Fri, 3 Nov 2006 09:43:31 +0100 Subject: [EMBOSS] Emboss-explorer error - Checked by AntiVir DEMO version - In-Reply-To: <454A1396.3020501@indiana.edu> References: <454A1396.3020501@indiana.edu> Message-ID: <20061103084331.GA16016@bigben.ulb.ac.be> On Thu, Nov 02, 2006 at 10:49:42AM -0500, Sumit Middha wrote: > I have setup emboss-explorer and it works fine for most of the tools. > However, fuzznuc, fuzztran seem to give an error (unknown datatype > pattern). That is because in EMBOSS 4 the ACD file for the "fuzzies" have a new datatype called "pattern" ; also, the option "number of allowed mismatches" is now an attribute of "pattern" rather than a separate ACD parameter. Maybe you can send a message to Luke and ask him to mend this. Note by the way that the new version of the interface wEMBOSS, which can handle all the EMBOSS 4 intricacies, is just out. Guy Bottu, Belgian EMBnet Node From pmr at ebi.ac.uk Fri Nov 3 11:01:42 2006 From: pmr at ebi.ac.uk (Peter Rice) Date: Fri, 03 Nov 2006 11:01:42 +0000 Subject: [EMBOSS] IDs in output In-Reply-To: <716af09c0611020816r3d5c30dg1b1c6f1f4d5fea5d@mail.gmail.com> References: <716af09c0611020816r3d5c30dg1b1c6f1f4d5fea5d@mail.gmail.com> Message-ID: <454B2196.8040905@ebi.ac.uk> Hi Bernd, Bernd Web wrote: > Hi, > > Sometimes I use an EMBOSS command directly on a FastA file. > I wonder if it is possible to select the ID used in the output, esp > for FastA records with an NCBI defline. > >> gi|248166|g|AA21972.1| description... > > in the output of an EMBOSS command becomes: > AA21972.1| > > It would be very easy if the ID could be chosen to be the GI number. > Now the ID used depends on the GI record (sp, pdb, pir) show different > IDs in EMBOSS output. Did you mistype the defline? There is a defined set of database names that can appear in NCBI deflines. If the "|g|" is really "gb" then the ID will be AA21972 which is what I would expect. If the database name is invalid (or a new one unknown to EMBOSS) then we could try to use the GI number. but the "EMBOSS way" would be to use the accession number from the sequence version. Unfortunately at present it is using the last part of sequence version "1" as the ID in your example. I will fix it for the next release. You can use -sid on the command line to give an ID to a sequence that does not have one,but not to replace an existing ID. That seems strange. It may change for the next release so that you can always use -sid to define the ID. Hope that helps Peter From maoj at helix.nih.gov Fri Nov 3 11:55:33 2006 From: maoj at helix.nih.gov (Jean Mao) Date: Fri, 3 Nov 2006 06:55:33 -0500 Subject: [EMBOSS] Emboss-explorer error - Checked by AntiVir DEMOversion - In-Reply-To: <20061103084331.GA16016@bigben.ulb.ac.be> Message-ID: <000b01c6ff3e$f7d36780$be4de780@CIT.NIH.GOV> Is there a temporary solution that I can do to EMBOSS-4.0.0 to fix the datatype errors instead of waiting for solution from Luke? I sent several emails to him but got no response at all for a long while. Thank you very much! Jean -----Original Message----- From: Guy Bottu [mailto:gbottu at ben.vub.ac.be] Sent: 2006?11?3? 3:44 To: Sumit Middha Cc: emboss at emboss.open-bio.org Subject: Re: [EMBOSS] Emboss-explorer error - Checked by AntiVir DEMOversion - On Thu, Nov 02, 2006 at 10:49:42AM -0500, Sumit Middha wrote: > I have setup emboss-explorer and it works fine for most of the tools. > However, fuzznuc, fuzztran seem to give an error (unknown datatype > pattern). That is because in EMBOSS 4 the ACD file for the "fuzzies" have a new datatype called "pattern" ; also, the option "number of allowed mismatches" is now an attribute of "pattern" rather than a separate ACD parameter. Maybe you can send a message to Luke and ask him to mend this. Note by the way that the new version of the interface wEMBOSS, which can handle all the EMBOSS 4 intricacies, is just out. Guy Bottu, Belgian EMBnet Node _______________________________________________ EMBOSS mailing list EMBOSS at lists.open-bio.org http://lists.open-bio.org/mailman/listinfo/emboss From bernd.web at gmail.com Fri Nov 3 12:29:35 2006 From: bernd.web at gmail.com (Bernd Web) Date: Fri, 3 Nov 2006 13:29:35 +0100 Subject: [EMBOSS] IDs in output In-Reply-To: <454B2196.8040905@ebi.ac.uk> References: <716af09c0611020816r3d5c30dg1b1c6f1f4d5fea5d@mail.gmail.com> <454B2196.8040905@ebi.ac.uk> Message-ID: <716af09c0611030429t606b4659wb553f7b8504669d3@mail.gmail.com> Hi Peter, Although I copy pasted, indeed the defline was wrong. It should have been: >gi|248166|gb|AAB21972.1| invertase {EC 3.2.1.26} [baker's yeast, Peptide Partial, 6 aa, segment 10 of 12] ATNTTL EMBOSS extracts "AAB21972.1". Having the version number is OK since otherwise the sequence is not completely defined (AAB21972 could refer to multiple versions). My idea was more related to selecting the GI number as ID to use in EMBOSS applications. Now the accession number depends on the format of the defline: sp -> Entry Name (not primary accession) ref, emb, gb -> Accesion pdb -> PDB protein name with Chain concatenated to it. Although I wrote a script to map the names from NCBI deflines to EMBOSS names, it could be easy to have the option to use the GI number. Regards, Bernd On 11/3/06, Peter Rice wrote: > Hi Bernd, > > Bernd Web wrote: > > Hi, > > > > Sometimes I use an EMBOSS command directly on a FastA file. > > I wonder if it is possible to select the ID used in the output, esp > > for FastA records with an NCBI defline. > > > >> gi|248166|g|AA21972.1| description... > > > > in the output of an EMBOSS command becomes: > > AA21972.1| > > > > It would be very easy if the ID could be chosen to be the GI number. > > Now the ID used depends on the GI record (sp, pdb, pir) show different > > IDs in EMBOSS output. > > Did you mistype the defline? There is a defined set of database names that can > appear in NCBI deflines. If the "|g|" is really "gb" then the ID will be AA21972 > which is what I would expect. > > If the database name is invalid (or a new one unknown to EMBOSS) then we could > try to use the GI number. but the "EMBOSS way" would be to use the accession > number from the sequence version. Unfortunately at present it is using the last > part of sequence version "1" as the ID in your example. I will fix it for the > next release. > > You can use -sid on the command line to give an ID to a sequence that does not > have one,but not to replace an existing ID. That seems strange. It may change > for the next release so that you can always use -sid to define the ID. > > Hope that helps > > Peter > > > > > From praneet at Sun.COM Fri Nov 3 11:59:06 2006 From: praneet at Sun.COM (praneet) Date: Fri, 03 Nov 2006 17:29:06 +0530 Subject: [EMBOSS] Parallelizing Emboss Message-ID: <454B2F0A.3030703@sun.com> Hello Everyone, We at Sun Microsystems just got started with Emboss. So, apologies if you don't find the questions asked below as particularly bright. We are evaluating Emboss and trying to figure out if it can be parallelized. Eventually, Emboss* may be* available on Sun Grid (http://www.sun.com/service/sungrid/overview.jsp and http://www.network.com/). I've a few questions 1. What do you think is the best way to parallelize Emboss? best here means we are ready for a cost performance trade-off. Our options are 1. Input partioning or 2. Writing mpi constructs 2. Are there any existing guidelines/ reference implementation/ docs or any relevant material pertaining to parallelizing Emboss? 3. Out of the 160 applications, which ones do you think should be parallelized? We don't have time to parallelize all applications if we go the mpi route. A starting list of 5 applications would serve our purpose. From what I could find on the net, palindrome and einverted seem to be slow. Are these two good candidates to get us started? Anything else that you think may enlighten us would be heartily welcome. Thanks in advance --praneet From pmr at ebi.ac.uk Fri Nov 3 13:31:40 2006 From: pmr at ebi.ac.uk (Peter Rice) Date: Fri, 03 Nov 2006 13:31:40 +0000 Subject: [EMBOSS] IDs in output In-Reply-To: <716af09c0611030429t606b4659wb553f7b8504669d3@mail.gmail.com> References: <716af09c0611020816r3d5c30dg1b1c6f1f4d5fea5d@mail.gmail.com> <454B2196.8040905@ebi.ac.uk> <716af09c0611030429t606b4659wb553f7b8504669d3@mail.gmail.com> Message-ID: <454B44BC.2000001@ebi.ac.uk> Bernd Web wrote: > Hi Peter, > > Although I copy pasted, indeed the defline was wrong. It should have been: > >> gi|248166|gb|AAB21972.1| invertase {EC 3.2.1.26} [baker's yeast, > Peptide Partial, 6 aa, segment 10 of 12] > ATNTTL > > EMBOSS extracts "AAB21972.1". > Having the version number is OK since otherwise the sequence is not > completely defined (AAB21972 could refer to multiple versions). If you specify -osformat ncbi you should be able to recreate the original defline in the EMBOSS output. > My idea was more related to selecting the GI number as ID to use in > EMBOSS applications. Now the accession number depends on the format of > the defline: > sp -> Entry Name (not primary accession) If there is an Entry name EMBOSS will use it. > ref, emb, gb -> Accesion But now EMBL and Genbank define this as the entry name anyway. > pdb -> PDB protein name with Chain concatenated to it. That seems good to me ... although we know of a problem when there are more than 26 chains and -a comes round again. > Although I wrote a script to map the names from NCBI deflines to > EMBOSS names, it could be easy to have the option to use the GI > number. Hmmm ..... in EMBOSS terms, this counts as yet another sequence format. We could make a new output format (-osformat gifasta for example) that uses the GI as the ID... but it would use the original sequence name as the filename first time around (and then when you read the file it would start using the GI number as the filename). But we could also make "gifasta" an input format (-sformat gifasta) and then it could use the GI number - but you would have to specify the -sformat on the command line (or gifasta::filename as input) because EMBOSS has to choose which way to interpret the defline. Does that solve your problem? NCBI regard the ID as the entire string with "|" characters embedded, but that is no use when making filenames so we had to choose something. EMBL does not use GI numbers ... they only appear in GenBank and NCBI files. I never liked them, but EMBOSS does try to do whatever the users demand :-) regards, Peter From paul.guermonprez at intel.com Fri Nov 3 13:55:41 2006 From: paul.guermonprez at intel.com (Guermonprez, Paul) Date: Fri, 3 Nov 2006 13:55:41 -0000 Subject: [EMBOSS] Parallelizing Emboss Message-ID: <48F17FCD4E8AB449BD956AF127AE4FD4E9FA85@IRSMSX411> hello, Glad to hear it, a good target may be "water", a smith waterman implementation. We had a similar topic on [emboss-dev] lately. Of course before parallelizing an algo the first step is to optimize it in serial mode, you may find information about emboss-water optimization done at intel a few months ago here : please find the pdf of the slides here : http://www.guermonprez.net/projects/emboss/emboss-EBI_06_06.pdf and the sources here (need emboss 3.0.0 to work) : http://www.guermonprez.net/projects/emboss/emboss-runsh.tar.gz the software speed gain ( x11 ) was measured on intel architecture but you can get more or less the same on different hardware too. regards, paul. Paul Guermonprez - Intel Sr. Software Engineer - Digital Health EMEA email : paul.guermonprez at intel.com phone : +33 1 58 87 72 41 mobile : +33 6 26 23 67 62 -----Original Message----- From: emboss-bounces at lists.open-bio.org [mailto:emboss-bounces at lists.open-bio.org] On Behalf Of praneet Sent: Friday, November 03, 2006 12:59 PM To: emboss at lists.open-bio.org Subject: [EMBOSS] Parallelizing Emboss Hello Everyone, We at Sun Microsystems just got started with Emboss. So, apologies if you don't find the questions asked below as particularly bright. We are evaluating Emboss and trying to figure out if it can be parallelized. Eventually, Emboss* may be* available on Sun Grid (http://www.sun.com/service/sungrid/overview.jsp and http://www.network.com/). I've a few questions 1. What do you think is the best way to parallelize Emboss? best here means we are ready for a cost performance trade-off. Our options are 1. Input partioning or 2. Writing mpi constructs 2. Are there any existing guidelines/ reference implementation/ docs or any relevant material pertaining to parallelizing Emboss? 3. Out of the 160 applications, which ones do you think should be parallelized? We don't have time to parallelize all applications if we go the mpi route. A starting list of 5 applications would serve our purpose. From what I could find on the net, palindrome and einverted seem to be slow. Are these two good candidates to get us started? Anything else that you think may enlighten us would be heartily welcome. Thanks in advance --praneet _______________________________________________ EMBOSS mailing list EMBOSS at lists.open-bio.org http://lists.open-bio.org/mailman/listinfo/emboss From msarachu at biol.unlp.edu.ar Fri Nov 3 15:41:26 2006 From: msarachu at biol.unlp.edu.ar (=?ISO-8859-1?Q?Mart=EDn_Sarachu?=) Date: Fri, 03 Nov 2006 12:41:26 -0300 Subject: [EMBOSS] wrappers4EMBOSS-1.5.1 released Message-ID: <454B6326.1000907@biol.unlp.edu.ar> This release adds some extra toggle buttons for muscle, phiblast and psiblast to comply to wEMBOSS not allowing users to choose name for output files. These programs needs to create extra files and thus the toggle buttons allow it under wEMBOSS. wrappers4EMBOSS can de downloaded from http://www.wemboss.org Best regards, The wrappers4EMBOSS team From gbottu at ben.vub.ac.be Sun Nov 5 19:15:56 2006 From: gbottu at ben.vub.ac.be (Guy Bottu) Date: Sun, 5 Nov 2006 20:15:56 +0100 Subject: [EMBOSS] using emboss programs from spin] - Checked by AntiVir DEMO version In-Reply-To: <4549A594.4050205@yahoo.es> References: <4549A594.4050205@yahoo.es> Message-ID: <20061105191556.GA21963@bigben.ulb.ac.be> On Thu, Nov 02, 2006 at 09:00:20AM +0100, Miguel Ortiz Lombardia wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Here, a number of users are quite afraid of the command line ;-{ so they > would appreciate a graphic interface to EMBOSS. We tried Jemboss first, > but got a number of problems that we couldn't solve (essentially with > some results text files being corrupted). Then, I met with this > interface from the Staden package, and found it very useful, to a > certain extent. Dear Miguel, If you want a GUI for EMBOSS another possibility is wEMBOSS, a Web interface with the user data permanently stored at the side of the server. A version that fully supports EMBOSS 4 is just out (see http://wemboss.sourceforge.net). However, I consider that Staden spin remains useful. When I personally have to do some bioinformatic analysis with EMBOSS, I usually work at the command line. But for programs that produce an XY-graph I use spin, because it has this nice feature of displaying in one window a zoomable graph and in another window the sequence, allowing to see which detail of the graph corresponds to which range of the sequence. Regards, Guy Bottu, BEN From golharam at umdnj.edu Tue Nov 7 03:57:56 2006 From: golharam at umdnj.edu (Ryan Golhar) Date: Mon, 06 Nov 2006 22:57:56 -0500 Subject: [EMBOSS] using emboss programs from spin] - Checked by AntiVirDEMO version In-Reply-To: <20061105191556.GA21963@bigben.ulb.ac.be> Message-ID: <002a01c70220$e92036c0$2f01a8c0@GOLHARMOBILE1> Take a look at the web site, http://emboss.sourceforge.net. There are a number of web interfaces available. They all have different strengths/weaknesses, so decide upon what it is you are looking for - that should help you choose one. > -----Original Message----- > From: emboss-bounces at lists.open-bio.org > [mailto:emboss-bounces at lists.open-bio.org] On Behalf Of Guy Bottu > Sent: Sunday, November 05, 2006 2:16 PM > To: Miguel Ortiz Lombardia > Cc: emboss at emboss.open-bio.org > Subject: Re: [EMBOSS] using emboss programs from spin] - > Checked by AntiVirDEMO version > > > On Thu, Nov 02, 2006 at 09:00:20AM +0100, Miguel Ortiz > Lombardia wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Here, a number of users are quite afraid of the command line ;-{ so > > they would appreciate a graphic interface to EMBOSS. We > tried Jemboss > > first, but got a number of problems that we couldn't solve > > (essentially with some results text files being corrupted). Then, I > > met with this interface from the Staden package, and found it very > > useful, to a certain extent. > > Dear Miguel, > > If you want a GUI for EMBOSS another possibility is wEMBOSS, > a Web interface with > the user data permanently stored at the side of the server. A > version that fully > supports EMBOSS 4 is just out (see http://wemboss.sourceforge.net). > > However, I consider that Staden spin remains useful. When I > personally have to do > some bioinformatic analysis with EMBOSS, I usually work at > the command line. But for > programs that produce an XY-graph I use spin, because it has > this nice feature of > displaying in one window a zoomable graph and in another > window the sequence, > allowing to see which detail of the graph corresponds to > which range of the > sequence. > > Regards, > Guy Bottu, > BEN > > _______________________________________________ > EMBOSS mailing list > EMBOSS at lists.open-bio.org > http://lists.open-> bio.org/mailman/listinfo/emboss > From ajb at ebi.ac.uk Wed Nov 8 14:18:05 2006 From: ajb at ebi.ac.uk (ajb at ebi.ac.uk) Date: Wed, 8 Nov 2006 14:18:05 -0000 (GMT) Subject: [EMBOSS] Jemboss patch on the EMBOSS ftp server Message-ID: <54309.81.98.244.247.1162995485.squirrel@webmail.ebi.ac.uk> There is now a fix for Jemboss on the EMBOSS ftp server. This fixes a problem involving the specification of mismatches in "the fuzzies" (i.e. fuzznuc etc). See the ftp://emboss.open-bio.org/pub/EMBOSS/fixes/README.fixes or the ftp://emboss.open-bio.org/pub/EMBOSS/fixes/patches/README.patch files to find out how to apply the fix. The patch-1-19.gz file in the patches directory will, of course, apply all fixes to date when used with a fresh download of EMBOSS-4.0.0.tar.gz. Alan From ajb at ebi.ac.uk Wed Nov 8 15:29:18 2006 From: ajb at ebi.ac.uk (ajb at ebi.ac.uk) Date: Wed, 8 Nov 2006 15:29:18 -0000 (GMT) Subject: [EMBOSS] email list problems fixed Message-ID: <40673.81.98.244.247.1162999758.squirrel@webmail.ebi.ac.uk> You may have experienced problems emailing the EMBOSS lists over the last couple of days. We understand that the problem has now been fixed. Thanks to the Open-Bio team for their usual prompt response. Alan From golharam at umdnj.edu Wed Nov 8 20:15:36 2006 From: golharam at umdnj.edu (Ryan Golhar) Date: Wed, 08 Nov 2006 15:15:36 -0500 Subject: [EMBOSS] Jemboss patch on the EMBOSS ftp server In-Reply-To: <54309.81.98.244.247.1162995485.squirrel@webmail.ebi.ac.uk> Message-ID: <00df01c70372$aaefdd30$2f01a8c0@GOLHARMOBILE1> Hi Alan, I downloaded and applied the patch file. Building EMBOSS fails. I looked into it more and it looks like there are some new additional files in jemboss, specifically in org/emboss/jemboss/gui/form. The patch file only mentioned that the file is new but it doesn't contain the contents of the file. Are the new files in the EMBOSS-4.0.0.tar.gz file or just available from the jemboss-08112006.jar file? Ryan > -----Original Message----- > From: emboss-bounces at lists.open-bio.org > [mailto:emboss-bounces at lists.open-bio.org] On Behalf Of ajb at ebi.ac.uk > Sent: Wednesday, November 08, 2006 9:18 AM > To: emboss at emboss.open-bio.org > Subject: [EMBOSS] Jemboss patch on the EMBOSS ftp server > > > There is now a fix for Jemboss on the EMBOSS ftp server. This > fixes a problem involving the specification of mismatches in > "the fuzzies" (i.e. fuzznuc etc). > > See the > ftp://emboss.open-> bio.org/pub/EMBOSS/fixes/README.fixes or > the > ftp://emboss.open-bio.org/pub/EMBOSS/fixes/patches/README.patch files to find out how to apply the fix. The patch-1-19.gz file in the patches directory will, of course, apply all fixes to date when used with a fresh download of EMBOSS-4.0.0.tar.gz. Alan _______________________________________________ EMBOSS mailing list EMBOSS at lists.open-bio.org http://lists.open-bio.org/mailman/listinfo/emboss From ajb at ebi.ac.uk Wed Nov 8 21:41:06 2006 From: ajb at ebi.ac.uk (ajb at ebi.ac.uk) Date: Wed, 8 Nov 2006 21:41:06 -0000 (GMT) Subject: [EMBOSS] Jemboss patch on the EMBOSS ftp server In-Reply-To: <00df01c70372$aaefdd30$2f01a8c0@GOLHARMOBILE1> References: <54309.81.98.244.247.1162995485.squirrel@webmail.ebi.ac.uk> <00df01c70372$aaefdd30$2f01a8c0@GOLHARMOBILE1> Message-ID: <35979.81.98.244.247.1163022066.squirrel@webmail.ebi.ac.uk> Hi Ryan, Thanks for pointing out the error. I've put a replacement patch-1-19.gz on the ftp server. Let me know if you still have a problem. Alan From golharam at umdnj.edu Thu Nov 9 05:54:22 2006 From: golharam at umdnj.edu (Ryan Golhar) Date: Thu, 09 Nov 2006 00:54:22 -0500 Subject: [EMBOSS] EMBOSS RPMs Message-ID: <00fa01c703c3$81b72d00$2f01a8c0@GOLHARMOBILE1> In case anyone is interested, I've rebuilt the EMBOSS RPMs to include the latest patch. They are available from the EMBOSS download page, or from http://informatics.umdnj.edu/BioRPMs Ryan From roberto.pava at gmail.com Thu Nov 9 15:53:50 2006 From: roberto.pava at gmail.com (Roberto Pava) Date: Thu, 9 Nov 2006 10:53:50 -0500 Subject: [EMBOSS] Help with equicktandem and etandem Message-ID: <1816142e0611090753g3e58215bh6982f5af78676413@mail.gmail.com> Hello, I'm a revision of methods to find repeats on biological sequences. I can't understand the algorithm of equicktandem and etandem. Please, somebody can send to me a description of algorithms or link where I cant find it. Thanks Roberto A. Pava http://roberto.pava.googlepages.com From gbottu at ben.vub.ac.be Thu Nov 9 19:00:07 2006 From: gbottu at ben.vub.ac.be (Guy Bottu) Date: Thu, 9 Nov 2006 20:00:07 +0100 Subject: [EMBOSS] about restriction mapping - Checked by AntiVir DEMO version - Message-ID: <20061109190007.GB106@bigben.ulb.ac.be> Dear EMBOSS team, While giving a course yesterday I was reminded of the following thing : Under GCG the restriction mapping programs have a parameter allowing to precise sequence ranges where enzymes are not allowed to cut. This can be very useful, e.g. when you want to select restriction enzymes that allow to cut out a gene to be cloned (which of course should not cut inside the gene). Would it not be nice if the EMBOSS programs had the same functionality ? Does anybody else also feel a need for this feature ? Guy Bottu, BEN From David.Lapointe at umassmed.edu Thu Nov 9 20:13:37 2006 From: David.Lapointe at umassmed.edu (Lapointe, David) Date: Thu, 9 Nov 2006 15:13:37 -0500 Subject: [EMBOSS] Adding Codon Tables Message-ID: <7D402AC3CCB55742BEBBA6C3031C29083A6B69@edunivmail01.ad.umassmed.edu> I created a new codon table (EGC.24) and added an entry to the end of EGC.index, but transeq does not accept table values outside of 0..23. What is the procedure for adding a new codon table? David David Lapointe, Ph.D. Manager - Research Computing UMass Medical School Worcester MA 01655 508-856-7600 From pmr at ebi.ac.uk Thu Nov 9 23:26:11 2006 From: pmr at ebi.ac.uk (pmr at ebi.ac.uk) Date: Thu, 9 Nov 2006 23:26:11 -0000 (GMT) Subject: [EMBOSS] Adding Codon Tables In-Reply-To: <7D402AC3CCB55742BEBBA6C3031C29083A6B69@edunivmail01.ad.umassmed.edu> References: <7D402AC3CCB55742BEBBA6C3031C29083A6B69@edunivmail01.ad.umassmed.edu> Message-ID: <1403.86.132.218.102.1163114771.squirrel@webmail.ebi.ac.uk> Dear David, > I created a new codon table (EGC.24) and added an entry to the end of > EGC.index, but transeq > does not accept table values outside of 0..23. > > What is the procedure for adding a new codon table? The transeq.acd file has a list of known genetic codes. We have the capability to automate the list, but it is a little tricky for those who write ACD parsers. As nobody has complained in version 4.0.0 we will automate it to use the EGC.index file for all applications in a future release. regards, Peter From pmr at ebi.ac.uk Thu Nov 9 23:30:07 2006 From: pmr at ebi.ac.uk (pmr at ebi.ac.uk) Date: Thu, 9 Nov 2006 23:30:07 -0000 (GMT) Subject: [EMBOSS] about restriction mapping - Checked by AntiVir DEMO version - In-Reply-To: <20061109190007.GB106@bigben.ulb.ac.be> References: <20061109190007.GB106@bigben.ulb.ac.be> Message-ID: <1414.86.132.218.102.1163115007.squirrel@webmail.ebi.ac.uk> Dear Guy, > While giving a course yesterday I was reminded of the following thing : > Under GCG the restriction mapping programs have a parameter allowing to > precise sequence ranges where enzymes are not allowed to cut. This can be > very useful, e.g. when you want to select restriction enzymes that allow > to cut out a gene to be cloned (which of course should not cut inside the > gene). Would it not be nice if the EMBOSS programs had the same > functionality ? Does anybody else also feel a need for this feature ? Easy to add as a set of ranges with a new qualifier. All we need is to know how many users want us to do it. regards, Peter From pmr at ebi.ac.uk Thu Nov 9 23:47:15 2006 From: pmr at ebi.ac.uk (pmr at ebi.ac.uk) Date: Thu, 9 Nov 2006 23:47:15 -0000 (GMT) Subject: [EMBOSS] Help with equicktandem and etandem In-Reply-To: <1816142e0611090753g3e58215bh6982f5af78676413@mail.gmail.com> References: <1816142e0611090753g3e58215bh6982f5af78676413@mail.gmail.com> Message-ID: <1557.86.132.218.102.1163116035.squirrel@webmail.ebi.ac.uk> Hi Roberto, > Hello, I'm a revision of methods to find repeats on biological > sequences. I can't understand the algorithm of equicktandem and > etandem. > > Please, somebody can send to me a description of algorithms or link > where I can find it. These programs were written by Richard Durbin at the Sanger Institute. Unfortunately there was never any documentation of the algorithms so we have to try to understand them by reading the source code. I will have another try at interpreting what is happening and update the documentation. Do you have any specific questions about how they work? regards, Peter Rice From henrikki.almusa at medicel.com Fri Nov 10 08:50:28 2006 From: henrikki.almusa at medicel.com (Henrikki Almusa) Date: Fri, 10 Nov 2006 10:50:28 +0200 Subject: [EMBOSS] Adding Codon Tables In-Reply-To: <1403.86.132.218.102.1163114771.squirrel@webmail.ebi.ac.uk> References: <7D402AC3CCB55742BEBBA6C3031C29083A6B69@edunivmail01.ad.umassmed.edu> <1403.86.132.218.102.1163114771.squirrel@webmail.ebi.ac.uk> Message-ID: <45543D54.3090309@medicel.com> pmr at ebi.ac.uk wrote: >> I created a new codon table (EGC.24) and added an entry to the end of >> EGC.index, but transeq >> does not accept table values outside of 0..23. >> >> What is the procedure for adding a new codon table? > > The transeq.acd file has a list of known genetic codes. > > We have the capability to automate the list, but it is a little tricky for > those who write ACD parsers. As nobody has complained in version 4.0.0 we > will automate it to use the EGC.index file for all applications in a > future release. By the way. I hope that the added codon files get new numbers in the ACD files? Mainly as if people have scripts (or other automated workflows) the meaning the numbers should not change later on. Same of course is a concern for any automation that is added if it has an effect on the user interfaces. Regards, -- Henrikki Almusa Medicel Oy Phone: +358 9 386 7092 http://www.medicel.com From golharam at umdnj.edu Sat Nov 11 04:49:32 2006 From: golharam at umdnj.edu (Ryan Golhar) Date: Fri, 10 Nov 2006 23:49:32 -0500 Subject: [EMBOSS] Emboss-explorer error - Checked by AntiVir DEMOversion - In-Reply-To: <000b01c6ff3e$f7d36780$be4de780@CIT.NIH.GOV> Message-ID: <000501c7054c$c97240f0$2f01a8c0@GOLHARMOBILE1> > -----Original Message----- > From: emboss-bounces at lists.open-bio.org > [mailto:emboss-bounces at lists.open-bio.org] On Behalf Of Jean Mao > Sent: Friday, November 03, 2006 6:56 AM > To: 'Guy Bottu'; Sumit Middha > Cc: emboss at emboss.open-bio.org > Subject: Re: [EMBOSS] Emboss-explorer error - Checked by > AntiVir DEMOversion - > > > Is there a temporary solution that I can do to EMBOSS-4.0.0 > to fix the datatype errors instead of waiting for solution > from Luke? I sent several emails to him but got no response > at all for a long while. Thank you very much! > > Jean I have a fix to this: In the XHTML.pm file, located in /usr/lib/perl5/site_perl/5.8.0/EMBOSS/GUI, you can apply this patch: ---BEGIN--- --- XHTML.pm 2006-11-10 23:38:31.000000000 -0500 +++ /usr/lib/perl5/site_perl/5.8.0/EMBOSS/GUI/XHTML.pm 2006-11-10 23:41:34.000000000 -0500 @@ -955,6 +955,10 @@ &_acd_infile; } +sub _acd_pattern { + &_text_field_html; +} + sub _acd_sequence { my ($self, $param) = @_; ---END--- Basically, add the function _acd_pattern to XHTML.pm. I can email you a fresh copy of XHTML.pm if you would like instead of applying a patch. I'll post this fix up on sourceforge as well. Ryan From mthon at tamu.edu Sun Nov 12 12:27:20 2006 From: mthon at tamu.edu (Michael Thon) Date: Sun, 12 Nov 2006 06:27:20 -0600 Subject: [EMBOSS] tranalign errors Message-ID: <9229557C-0B64-45B1-81CC-B7545B9F5403@tamu.edu> Hello - I'm trying to use tranalign to align DNA sequences but it keeps throwing errors. I tested it on the example input files from the documentation web pages and those work fine. here's an example session with the errors: tranalign fasta::stm1likedna.fasta fasta::stm1_prot_aln.fasta Align nucleic coding regions given the aligned proteins nucleotide output sequence set [ss1g01814.fasta]: Error: Guide protein sequence SS1G01814 not found in nucleic sequence SS1G01814 it throws the same error for every pair of proteins in the file here are the sequence names in the files. I can supply the full files if anyone thinks they can help. thanks in advance... Mike [mike at mikes-laptop phylo]$ grep '>' stm1likedna.fasta >SS1G01814 >SS1G03605 >SS1G07709 >SS1G11564 >BC1G02874 >BC1G08371 >BC1G15724 [mike at mikes-laptop phylo]$ grep '>' stm1_prot_aln.fasta >SS1G01814 >SS1G03605 >SS1G07709 >SS1G11564 >BC1G02874 >BC1G08371 >BC1G15724 From pmr at ebi.ac.uk Sun Nov 12 17:11:00 2006 From: pmr at ebi.ac.uk (pmr at ebi.ac.uk) Date: Sun, 12 Nov 2006 17:11:00 -0000 (GMT) Subject: [EMBOSS] tranalign errors In-Reply-To: <9229557C-0B64-45B1-81CC-B7545B9F5403@tamu.edu> References: <9229557C-0B64-45B1-81CC-B7545B9F5403@tamu.edu> Message-ID: <2564.86.132.218.102.1163351460.squirrel@webmail.ebi.ac.uk> > Hello - I'm trying to use tranalign to align DNA sequences but it > keeps throwing errors. I tested it on the example input files from > the documentation web pages and those work fine. > > Error: Guide protein sequence SS1G01814 not found in nucleic sequence > SS1G01814 > > it throws the same error for every pair of proteins in the file > > here are the sequence names in the files. I can supply the full > files if anyone thinks they can help. Yes, please send the full files to emboss-bug at emboss.open-bio.org The message is not an ID mismatch - it says the protein sequence did not match the DNA sequence. regards, Peter Rice From mccarthy at users.sourceforge.net Mon Nov 13 02:36:06 2006 From: mccarthy at users.sourceforge.net (Luke McCarthy) Date: Sun, 12 Nov 2006 20:36:06 -0600 Subject: [EMBOSS] EMBOSS explorer 2.2.0 Message-ID: <4557DA16.8000909@users.sourceforge.net> Hi all, EMBOSS explorer 2.2.0 has just been released, after a long delay. It has been updated to work with EMBOSS 4.0.0 (though it should continue to work with EMBOSS 3) Visit http://embossgui.sourceforge.net for more information or to download. Please report any problems using the bug tracker (available from the website above), or by email to mccarthy at users.sourceforge.net. Cheers, Luke From smiddha at indiana.edu Tue Nov 14 05:59:08 2006 From: smiddha at indiana.edu (Sumit) Date: Tue, 14 Nov 2006 00:59:08 -0500 Subject: [EMBOSS] Emboss-explorer error - Checked by AntiVir DEMOversion - In-Reply-To: <000501c7054c$c97240f0$2f01a8c0@GOLHARMOBILE1> References: <000501c7054c$c97240f0$2f01a8c0@GOLHARMOBILE1> Message-ID: <45595B2C.5070703@indiana.edu> Thanks Ryan and others. The new emboss-explorer takes care of this. Sumit Ryan Golhar wrote: >>-----Original Message----- >>From: emboss-bounces at lists.open-bio.org >>[mailto:emboss-bounces at lists.open-bio.org] On Behalf Of Jean Mao >>Sent: Friday, November 03, 2006 6:56 AM >>To: 'Guy Bottu'; Sumit Middha >>Cc: emboss at emboss.open-bio.org >>Subject: Re: [EMBOSS] Emboss-explorer error - Checked by >>AntiVir DEMOversion - >> >> >>Is there a temporary solution that I can do to EMBOSS-4.0.0 >>to fix the datatype errors instead of waiting for solution >>from Luke? I sent several emails to him but got no response >>at all for a long while. Thank you very much! >> >>Jean >> >> > > >I have a fix to this: > >In the XHTML.pm file, located in >/usr/lib/perl5/site_perl/5.8.0/EMBOSS/GUI, you can apply this patch: > >---BEGIN--- >--- XHTML.pm 2006-11-10 23:38:31.000000000 -0500 >+++ /usr/lib/perl5/site_perl/5.8.0/EMBOSS/GUI/XHTML.pm 2006-11-10 >23:41:34.000000000 -0500 >@@ -955,6 +955,10 @@ > &_acd_infile; > } > >+sub _acd_pattern { >+ &_text_field_html; >+} >+ > sub _acd_sequence { > my ($self, $param) = @_; >---END--- > >Basically, add the function _acd_pattern to XHTML.pm. I can email you a >fresh copy of XHTML.pm if you would like instead of applying a patch. >I'll post this fix up on sourceforge as well. > >Ryan > > > > From david.guzman at uniklinik-freiburg.de Mon Nov 20 14:31:43 2006 From: david.guzman at uniklinik-freiburg.de (David Guzman) Date: Mon, 20 Nov 2006 15:31:43 +0100 Subject: [EMBOSS] seqret/entret problems using acc from ensembl-embl Message-ID: <4561BC4F.5010904@uniklinik-freiburg.de> Dear all, I am experiencing a very strange problem using seqret and entret. I have downloaded and indexed with dbiflat the database files from the Homo sapiens subsection of Ensembl (latest version as of Nov 15th). When I try to get one sequence with seqret or the complete entry with entret using the AC code I got the following error message: claudia at pc-31-18-86-200:~> seqret embldnahs:chromosome:NCBI36:1:1000001:1970768:1 Reads and writes (returns) sequences Error: Unable to read sequence 'embldnahs:chromosome:NCBI36:1:1000001:1970768:1' Died: seqret terminated: Bad value for '-sequence' and no prompt I think that the format used by Ensembl for assigning IDs and ACCs is causing the problems. For example the first entry from the flat file: claudia at pc-31-18-86-200:~> head /local/bioinfo/db/ensembl/embl/Homo_sapiens.0.dat ID 1 standard; DNA; HTG; 970768 BP. XX AC chromosome:NCBI36:1:1000001:1970768:1 XX SV chromosome:NCBI36:1:1000001:1970768:1 XX DT 5-OCT-2006 XX DE Homo sapiens chromosome 1 NCBI36 partial sequence 1000001..1970768 DE annotated by Ensembl I tried replacing the ":" character of the AC line with a "_" using sed but after indexing and I get the same error message with seqret or entret. Is there any length limit for IDs or ACCs in EMBOSS? Is there any workaround for this problem? Thanks System: EMBOSS 4.0.0 SUSE 9.3 showdb: # Name Type ID Qry All Comment # ============ ==== == === === ======= embldnahs N OK OK OK Ensembl EMBL DNA H.sapiens emboss.default DB embldnahs [ type: N dir: /local/bioinfo/db/ensembl/embl method: emblcd format: embl file: *.dat comment: "Ensembl EMBL DNA H.sapiens"] -------------- next part -------------- A non-text attachment was scrubbed... Name: david.guzman.vcf Type: text/x-vcard Size: 290 bytes Desc: not available URL: From pmr at ebi.ac.uk Mon Nov 20 15:52:31 2006 From: pmr at ebi.ac.uk (Peter Rice) Date: Mon, 20 Nov 2006 15:52:31 +0000 Subject: [EMBOSS] seqret/entret problems using acc from ensembl-embl In-Reply-To: <4561BC4F.5010904@uniklinik-freiburg.de> References: <4561BC4F.5010904@uniklinik-freiburg.de> Message-ID: <4561CF3F.4080802@ebi.ac.uk> Hi David, > I think that the format used by Ensembl for assigning IDs and ACCs is > causing the problems. For example the first entry from the flat file: > > claudia at pc-31-18-86-200:~> head > /local/bioinfo/db/ensembl/embl/Homo_sapiens.0.dat > ID 1 standard; DNA; HTG; 970768 BP. > XX > AC chromosome:NCBI36:1:1000001:1970768:1 > XX > SV chromosome:NCBI36:1:1000001:1970768:1 > XX > DT 5-OCT-2006 > XX > DE Homo sapiens chromosome 1 NCBI36 partial sequence 1000001..1970768 > DE annotated by Ensembl > > I tried replacing the ":" character of the AC line with a "_" using sed > but after indexing and I get the same error message with seqret or > entret. Is there any length limit for IDs or ACCs in EMBOSS? Is there > any workaround for this problem? Those IDs are horrible and not really EMBL format... certainly not valid accession numbers. We will add an ENSEMBL format for the next release... as a sequence format and as a format for dbiflat and the (preferred) dbxflat. Hope that helps, Peter From golergka at gmail.com Thu Nov 23 06:29:15 2006 From: golergka at gmail.com (Maxim Jankov) Date: Thu, 23 Nov 2006 09:29:15 +0300 Subject: [EMBOSS] Simple configuration of databases Message-ID: <940db11d0611222229m75313353m5bc0e357dffe37d9@mail.gmail.com> Hi, dear all :) I'm quite new to emboss and never been to serious administration routine, but now I need to have a proper installation of emboss at home (Ubuntu 6.10) for educational purposes (cos university server goes down often) - and not only emboss, but all the main databases, like swissprot, embl, pdb and for sure several more that I yet dunno about. Fortunately, I don't want to download all these gigabytes, and better configure emboss to work with all that db's online. But the bad thing is that I'm completely stuck in all that manuals and just begging for help of someone who done configuration like that and can provide me with ready or easy-to-understand config files. Thank you. From jerome at ibt.unam.mx Thu Nov 23 18:43:30 2006 From: jerome at ibt.unam.mx (Jerome) Date: Thu, 23 Nov 2006 12:43:30 -0600 Subject: [EMBOSS] How to indexing a bactria genome ? Message-ID: <4565EBD2.6040204@ibt.unam.mx> Hi all, I'm trying to use the flat file of a genome of a bacteria. As i can read in this file (U00096_GR.dat), i've get all the information about CDS, proteins and a lot more. For example, there is a information about "aspartate kinase activity".. And i would like to indexing this information as "Description" in my emboss database. But when i do the indexing, the result is just on sequence, the all geneme nuclear acid. I don't know if dbiflat permits what i want to do, or i would use another type of flat file?. Thank's. Best Regards. -- -- J?r?me Maman ach?te souvent des cravates pour papa, mais papa ne les met presque jamais. Elles sont si belles qu'il doit avoir peur de les salir. (Histoires in?dites du Petit Nicolas, Goscinny & Semp?) From gbottu at ben.vub.ac.be Thu Nov 23 19:02:45 2006 From: gbottu at ben.vub.ac.be (Guy Bottu) Date: Thu, 23 Nov 2006 20:02:45 +0100 Subject: [EMBOSS] Simple configuration of databases - Checked by AntiVir DEM In-Reply-To: <940db11d0611222229m75313353m5bc0e357dffe37d9@mail.gmail.com> References: <940db11d0611222229m75313353m5bc0e357dffe37d9@mail.gmail.com> Message-ID: <20061123190245.GB32105@bigben.ulb.ac.be> On Thu, Nov 23, 2006 at 09:29:15AM +0300, Maxim Jankov wrote: > Fortunately, I don't want to download all these gigabytes, and better > configure emboss to work with all that db's online. But the bad thing is > that I'm completely stuck in all that manuals and just begging for help of > someone who done configuration like that and can provide me with ready or > easy-to-understand config files. Dear Maxim, I can provide you just like that with some remote databank definitions we use at the BEN site. Put in your file .../share/EMBOSS/emboss.default : DB NCBI_NUC [ type: N method: entrez format: genbank comment: 'nonredundant nuc. acid db at NCBI (by GI number)' ] DB NCBI_PROT [ type: P method: entrez format: genbank comment: 'nonredundant protein db at NCBI (by GI number)' ] DB EBI_EMBL [ type: N methodquery: external format: embl comment: 'EMBL at EBI' app: '/opt/sw/EBIWS/WSDbfetchClient.pl fetchData embl:%s' ] DB EBI_EMBLSVA [ type: N methodquery: external format: embl comment: 'EMBL Sequence Version Archive at EBI (by SV)' app: '/opt/sw/EBIWS/WSDbfetchClient.pl fetchData emblsva:%s' ] DB EBI_EMBLCDS [ type: N methodquery: external format: embl comment: 'EMBL Coding Sequences at EBI (by ProteinID)' app: '/opt/sw/EBIWS/WSDbfetchClient.pl fetchData emblcds:%s' ] Note : EMBOSS does have a databank access method "dbfetch", but I never managed to get it working (can someone who did tell me how ?). Instead I use the script WSDbfetchClient.pl (see attachment). To make it work you will need to install in your Perl the module SOAP-Lite (version 0.60 and not higher !). You will have to adapt the "app" parameter here above and the "shebang line" of the script. Regards, Guy Bottu, Belgian EMBnet Node -------------- next part -------------- A non-text attachment was scrubbed... Name: WSDbfetchClient.pl Type: application/x-perl Size: 3103 bytes Desc: not available URL: From pmr at ebi.ac.uk Thu Nov 23 23:58:22 2006 From: pmr at ebi.ac.uk (pmr at ebi.ac.uk) Date: Thu, 23 Nov 2006 23:58:22 -0000 (GMT) Subject: [EMBOSS] How to indexing a bactria genome ? In-Reply-To: <4565EBD2.6040204@ibt.unam.mx> References: <4565EBD2.6040204@ibt.unam.mx> Message-ID: <2613.81.178.231.206.1164326302.squirrel@webmail.ebi.ac.uk> Hi Jerome, > I'm trying to use the flat file of a genome of a bacteria. > As i can read in this file (U00096_GR.dat), i've get all the information > about CDS, proteins and a lot more. For example, there is a information > about "aspartate kinase activity".. And i would like to indexing this > information as "Description" in my emboss database. > > But when i do the indexing, the result is just on sequence, the all > geneme nuclear acid. > I don't know if dbiflat permits what i want to do, or i would use > another type of flat file?. We had the same request from Rodrigo Lopez at EBI a few weeks ago. We are thinking about the best way to do it. We have to make names for the "entries", and allow retrieval of single features. For CDS features we may want to index also as a protein database. Bacterial genomes are simple cases - we also have to consider eukaryote genomic contigs where CDSs are ascorr more than one entry. We hope to have a prototype available in the next release. How many other users are interested in indexing CDSs? Any suggestions for how to name the CDS "entries"? regards, Peter From michael.watson at bbsrc.ac.uk Mon Nov 27 13:57:46 2006 From: michael.watson at bbsrc.ac.uk (michael watson (IAH-C)) Date: Mon, 27 Nov 2006 13:57:46 -0000 Subject: [EMBOSS] Transeq and very large sequences Message-ID: <8975119BCD0AC5419D61A9CF1A923E9503E2E4A8@iahce2ksrv1.iah.bbsrc.ac.uk> Hi I want to translate very large (eukrayotic chromosomes!) DNA sequences in all 6 frames. Transeq takes about a day per large chromosome, running on a linux machine with 3Gb of RAM. Any suggestions on alternatives or how I could speed it up? Thanks Mick The information contained in this message may be confidential or legally privileged and is intended solely for the addressee. If you have received this message in error please delete it & notify the originator immediately. Unauthorised use, disclosure, copying or alteration of this message is forbidden & may be unlawful. The contents of this e-mail are the views of the sender and do not necessarily represent the views of the Institute. This email and associated attachments has been checked locally for viruses but we can accept no responsibility once it has left our systems. Communications on Institute computers are monitored to secure the effective operation of the systems and for other lawful purposes. From pmr at ebi.ac.uk Mon Nov 27 15:15:25 2006 From: pmr at ebi.ac.uk (Peter Rice) Date: Mon, 27 Nov 2006 15:15:25 +0000 Subject: [EMBOSS] Transeq and very large sequences In-Reply-To: <8975119BCD0AC5419D61A9CF1A923E9503E2E4A8@iahce2ksrv1.iah.bbsrc.ac.uk> References: <8975119BCD0AC5419D61A9CF1A923E9503E2E4A8@iahce2ksrv1.iah.bbsrc.ac.uk> Message-ID: <456B010D.6090807@ebi.ac.uk> michael watson (IAH-C) wrote: > I want to translate very large (eukrayotic chromosomes!) DNA sequences > in all 6 frames. Transeq takes about a day per large chromosome, > running on a linux machine with 3Gb of RAM. > > Any suggestions on alternatives or how I could speed it up? You want just a 6-frame translation of an entire chromosome? I will look into why it takes so long. We have made some changes to string size extension that may already help this for the next release. regards, Peter From michael.watson at bbsrc.ac.uk Mon Nov 27 15:47:17 2006 From: michael.watson at bbsrc.ac.uk (michael watson (IAH-C)) Date: Mon, 27 Nov 2006 15:47:17 -0000 Subject: [EMBOSS] Transeq and very large sequences In-Reply-To: <456B010D.6090807@ebi.ac.uk> Message-ID: <8975119BCD0AC5419D61A9CF1A923E9503E2E4AD@iahce2ksrv1.iah.bbsrc.ac.uk> Hi Peter Yes, a 6-frame translation of a chromosome :) It was meant to be part of a quick-and-dirty analysis method, but is proving to be anything but quick.... Mick -----Original Message----- From: Peter Rice [mailto:pmr at ebi.ac.uk] Sent: 27 November 2006 15:15 To: michael watson (IAH-C) Cc: emboss at lists.open-bio.org Subject: Re: [EMBOSS] Transeq and very large sequences michael watson (IAH-C) wrote: > I want to translate very large (eukrayotic chromosomes!) DNA sequences > in all 6 frames. Transeq takes about a day per large chromosome, > running on a linux machine with 3Gb of RAM. > > Any suggestions on alternatives or how I could speed it up? You want just a 6-frame translation of an entire chromosome? I will look into why it takes so long. We have made some changes to string size extension that may already help this for the next release. regards, Peter From michael.watson at bbsrc.ac.uk Mon Nov 27 16:32:25 2006 From: michael.watson at bbsrc.ac.uk (michael watson (IAH-C)) Date: Mon, 27 Nov 2006 16:32:25 -0000 Subject: [EMBOSS] Transeq and very large sequences In-Reply-To: Message-ID: <8975119BCD0AC5419D61A9CF1A923E9503E2E4B4@iahce2ksrv1.iah.bbsrc.ac.uk> Excellent! I set the MAXSEQIN paramter to 200,000,000 and it ran in 18 seconds.... -----Original Message----- From: David Mathog [mailto:mathog at caltech.edu] Sent: 27 November 2006 16:16 To: michael watson (IAH-C) Cc: emboss at lists.open-bio.org Subject: Re: [EMBOSS] Transeq and very large sequences On Mon, 27 Nov 2006, michael watson (IAH-C) wrote: > Hi > > I want to translate very large (eukrayotic chromosomes!) DNA sequences > in all 6 frames. Transeq takes about a day per large chromosome, > running on a linux machine with 3Gb of RAM. Well, you might try my fasttrans program. It may not do exactly what you want though. If the input sequence is bigger than 100kb it automatically fragments the input into 101kb chunks with a 1kb overlap. You could easily modify the code to make that chunk size so large that the whole chromosome would be read. I just tested it on Human chromosome 10 and it took 29 seconds on an Opteron system to do all 6 frames with the command: % time gunzip -c Homo_sapiens.NCBI36.41.dna.chromosome.10.fa.gz | fasttrans 123456 > foo.out ftp://saf.bio.caltech.edu/pub/software/molbio/fasttrans.c As for fixing the original problem, without looking at the code I'm going to hazard a wild guess. The program may be allocating smallish chunks for a buffer and then searching from the front of the buffer for the new end each time. This bug is never obvious when there are only a few chunks added but the time goes up as the square of the length if innumerable chunks must be added. So when presented with an input 100 times bigger than typical test cases the run time takes 10000 times longer, which sounds more or less like what you're seeing. Regards, David Mathog mathog at caltech.edu From pmr at ebi.ac.uk Mon Nov 27 16:59:49 2006 From: pmr at ebi.ac.uk (Peter Rice) Date: Mon, 27 Nov 2006 16:59:49 +0000 Subject: [EMBOSS] Transeq and very large sequences In-Reply-To: <8975119BCD0AC5419D61A9CF1A923E9503E2E4B4@iahce2ksrv1.iah.bbsrc.ac.uk> References: <8975119BCD0AC5419D61A9CF1A923E9503E2E4B4@iahce2ksrv1.iah.bbsrc.ac.uk> Message-ID: <456B1985.8080305@ebi.ac.uk> michael watson (IAH-C) wrote: > Excellent! I set the MAXSEQIN paramter to 200,000,000 and it ran in 18 > seconds.... Ah, that is a challenge. I'll see what I can do with the EMBOSS code :-) regards, Peter From mathog at caltech.edu Mon Nov 27 20:06:06 2006 From: mathog at caltech.edu (David Mathog) Date: Mon, 27 Nov 2006 12:06:06 -0800 Subject: [EMBOSS] Transeq and very large sequences Message-ID: On Mon, 27 Nov 2006, michael watson (IAH-C) wrote: > Hi > > I want to translate very large (eukrayotic chromosomes!) DNA sequences > in all 6 frames. Transeq takes about a day per large chromosome, > running on a linux machine with 3Gb of RAM. Well, you might try my fasttrans program. It may not do exactly what you want though. If the input sequence is bigger than 100kb it automatically fragments the input into 101kb chunks with a 1kb overlap. You could easily modify the code to make that chunk size so large that the whole chromosome would be read. I just tested it on Human chromosome 10 and it took 29 seconds on an Opteron system to do all 6 frames with the command: % time gunzip -c Homo_sapiens.NCBI36.41.dna.chromosome.10.fa.gz | fasttrans 123456 > foo.out ftp://saf.bio.caltech.edu/pub/software/molbio/fasttrans.c As for fixing the original problem, without looking at the code I'm going to hazard a wild guess. The program may be allocating smallish chunks for a buffer and then searching from the front of the buffer for the new end each time. This bug is never obvious when there are only a few chunks added but the time goes up as the square of the length if innumerable chunks must be added. So when presented with an input 100 times bigger than typical test cases the run time takes 10000 times longer, which sounds more or less like what you're seeing. Regards, David Mathog mathog at caltech.edu Manager, Sequence Analysis Facility, Biology Division, Caltech From tsirigos at gmail.com Tue Nov 28 20:17:10 2006 From: tsirigos at gmail.com (Aristotelis Tsirigos) Date: Tue, 28 Nov 2006 15:17:10 -0500 Subject: [EMBOSS] EMBOSS database setup Message-ID: <639b80db0611281217i6c1cc927v50ac9b8e6a71717c@mail.gmail.com> I just installed EMBOSS on my laptop by compiling the source codes under cygwin. Then, I tried to follow the online tutorial, but I encountered several problems. The main problem is that I don't have access to any of the databases, so I am wondering if there is a need for some kind of configuration. For example, showdb was initially showing no databases, until I renamed file ' emboss.default.template' to 'emboss.default'. Then, it showed some databases such as genbank. But when I used seqret to retrieve an entry from that database, it doesn't find anything... Is there a need for database configuration? Is it not possible to access databases remotely? Is there any tutorial that explains how to properly setup your data? Thanks! Aris From maoj at helix.nih.gov Thu Nov 30 13:57:24 2006 From: maoj at helix.nih.gov (Jean Mao) Date: Thu, 30 Nov 2006 08:57:24 -0500 Subject: [EMBOSS] Question regarding Reference Sequence Database Message-ID: <000001c71487$76d7e7b0$be4de780@CIT.NIH.GOV> Hi, Does any program in EMBOSS package can make use of the Reference Sequence Databases? I indexed refseq databases with dbxflat and run showfeat against them but receive error about has zero length sequence : Warning: Sequence 'refseqnt-id:NG_002612' has zero length, ignored Error: Unable to read sequence 'refseqnt:NG_002612' Thanks! Jean From pmr at ebi.ac.uk Thu Nov 30 14:36:06 2006 From: pmr at ebi.ac.uk (Peter Rice) Date: Thu, 30 Nov 2006 14:36:06 +0000 Subject: [EMBOSS] Question regarding Reference Sequence Database In-Reply-To: <000001c71487$76d7e7b0$be4de780@CIT.NIH.GOV> References: <000001c71487$76d7e7b0$be4de780@CIT.NIH.GOV> Message-ID: <456EEC56.5090108@ebi.ac.uk> Hi Jean, > Does any program in EMBOSS package can make use of the Reference Sequence > Databases? I indexed refseq databases with dbxflat and run showfeat against > them but receive error about has zero length sequence : The next release will include refseq as a valid sequence format. You can usually get away with defining the format as Genbank. If that does not work please let me know and I will update the refseq format code. Aha ... but in this case ... NG_002612 does have zero length. This appears to be one of those entries (the EMBL CON division does much the same) that only refer to sequence data in other entries. It ends with the line: CONTIG join(complement(AC006998.3:2483..110100)) We can try to process these. The database defintion will need to know where to look up "AC006998.3" which is where the sequence data ... and all the missing features ... should be. Can you exclude the CON entries from your indexing? if not, we can try excluding them. Hope that helps, Peter From simon.andrews at bbsrc.ac.uk Thu Nov 30 14:33:40 2006 From: simon.andrews at bbsrc.ac.uk (Simon Andrews) Date: Thu, 30 Nov 2006 14:33:40 +0000 Subject: [EMBOSS] Question regarding Reference Sequence Database In-Reply-To: <000001c71487$76d7e7b0$be4de780@CIT.NIH.GOV> References: <000001c71487$76d7e7b0$be4de780@CIT.NIH.GOV> Message-ID: On 30 Nov 2006, at 13:57, Jean Mao wrote: > Hi, > > Does any program in EMBOSS package can make use of the Reference > Sequence > Databases? I indexed refseq databases with dbxflat and run showfeat > against > them but receive error about has zero length sequence : > > Warning: Sequence 'refseqnt-id:NG_002612' has zero length, ignored > Error: > Unable to read sequence 'refseqnt:NG_002612' NG_ sequences in refseq are a bit odd. They're not real sequences but a virtual collection of other sequences which are joined together to make longer assemblies. The records themselves don't actually contain any sequence (hence the zero length sequence error), just pointers to parts of other sequences. On the NCBI website they have a facility to join the fragments together to create a 'real' sequence from them. You could probably do this if you had all the underlying sequences available, but it's not something which is likely to be possible during indexing. EMBOSS works fine with normal refseq files, but these virtual files are not something I'd say it was reasonable for it to cope with. It would be nice if NCBI offered an option to download rendered versions of these sequences, but as many of them are pretty big it might be a very large data set. TTFN Simon. From uludag at ebi.ac.uk Thu Nov 30 15:57:15 2006 From: uludag at ebi.ac.uk (Mahmut Uludag) Date: Thu, 30 Nov 2006 15:57:15 +0000 Subject: [EMBOSS] EMBOSS database setup In-Reply-To: <639b80db0611281217i6c1cc927v50ac9b8e6a71717c@mail.gmail.com> References: <639b80db0611281217i6c1cc927v50ac9b8e6a71717c@mail.gmail.com> Message-ID: <1164902235.14146.57.camel@emboss2.ebi.ac.uk> Hi Aris, > I just installed EMBOSS on my laptop by compiling the source codes under > cygwin. Then, I tried to follow the online tutorial, but I encountered > several problems. The main problem is that I don't have access to any of the > databases, so I am wondering if there is a need for some kind of > configuration. For example, showdb was initially showing no databases, until > I renamed file ' emboss.default.template' to 'emboss.default'. Then, it > showed some databases such as genbank. But when I used seqret to retrieve an > entry from that database, it doesn't find anything... Is there a need for > database configuration? Is it not possible to access databases remotely? Is > there any tutorial that explains how to properly setup your data? I thought the following message posted few days before your message may answer some of your questions. http://emboss.open-bio.org/pipermail/emboss/2006-November/002774.html Regards, Mahmut From ajb at ebi.ac.uk Thu Nov 30 16:27:40 2006 From: ajb at ebi.ac.uk (ajb at ebi.ac.uk) Date: Thu, 30 Nov 2006 16:27:40 -0000 (GMT) Subject: [EMBOSS] EMBOSS database setup In-Reply-To: <1164902235.14146.57.camel@emboss2.ebi.ac.uk> References: <639b80db0611281217i6c1cc927v50ac9b8e6a71717c@mail.gmail.com> <1164902235.14146.57.camel@emboss2.ebi.ac.uk> Message-ID: <43964.81.98.244.247.1164904060.squirrel@webmail.ebi.ac.uk> The appended definitions are simple ones that may be useful if you only want a few sequences at a time. If sites upgrade to SRS8 then alter accordingly. Alan DB embl [ type: N method: srswww format: embl release: "EBI" url: "http://srs.ebi.ac.uk/srs7bin/cgi-bin/wgetz" comment: "EMBL from the EBI" ] DB em [ type: N method: srswww format: embl release: "EBI" url: "http://srs.ebi.ac.uk/srs7bin/cgi-bin/wgetz" dbalias: "EMBL" comment: "EMBL from the EBI" ] DB swissprot [ type: P method: srswww format: swiss release: "EBI" url: "http://srs.ebi.ac.uk/srs7bin/cgi-bin/wgetz" comment: "SWISSPROT from the EBI" ] DB sw [ type: P method: srswww format: swiss release: "EBI" url: "http://srs.ebi.ac.uk/srs7bin/cgi-bin/wgetz" dbalias: "SWISSPROT" comment: "SWISSPROT from the EBI" ] DB uniprot [ type: P method: srswww format: swiss release: "EBI" url: "http://srs.ebi.ac.uk/srs7bin/cgi-bin/wgetz" comment: "UNIPROT from the EBI" ] DB uni [ type: P method: srswww format: swiss release: EBI url: "http://srs.ebi.ac.uk/srs7bin/cgi-bin/wgetz" dbalias: "UNIPROT" comment: "UNIPROT from the EBI" ] DB pir [ type: P method: srswww format: nbrf release: "EBI" url: "http://srs.ebi.ac.uk/srs7bin/cgi-bin/wgetz" comment: "PIR from the EBI" ] DB genbank [ type: N method: srswww format: genbank release: "NCBI" url: "http://www.infobiogen.fr/srs7bin/cgi-bin/wgetz" comment: "GenBank from Infobiogen" ] DB gb [ type: N method: srswww format: genbank release: "NCBI" url: "http://www.infobiogen.fr/srs7bin/cgi-bin/wgetz" dbalias: "GENBANK" comment: "GenBank from Infobiogen" ] DB refseq [ type: N method: srswww format: genbank release: "NCBI" url: "http://srs.ebi.ac.uk/srs7bin/cgi-bin/wgetz" comment: "REFSEQ from EBI" ]