[greigite]

There is a file /usr/lib64/libtk8.4.so, but using

--with-tklib=/usr/lib64 or --with-tklib=/usr/lib64/libtk8.4.so

also gives the same error. Could this be a 64 bit issue or the file being named "libtk8.4.so" instead of "tk8.4.so"? I'll give your precompiled binaries a shot also.

Hmm, is there not a /usr/lib/tk8.4.so (or /usr/lib/tk8.5.so)? The version number is important, and appears to be how all systems package up their tcl/tk distributions - well until Gentoo perhaps! I'm just using the supplied tcl.m4 for my autoconf detection too, so I'm guessing other packages relying on tcl/tk will fail to compile cleanly on this system as well.

What Gentoo version is this? I may be able to find a vmplayer image and give it a test myself.

However have you tried the prebuilt binaries too? They're not as new, but mainly the change to 2.0 was a major coding / file layout reshuffle.

James

[jkbonfield]

There is a file /usr/lib64/libtk8.4.so, but using

--with-tklib=/usr/lib64 or --with-tklib=/usr/lib64/libtk8.4.so

also gives the same error. Could this be a 64 bit issue or the file being named "libtk8.4.so" instead of "tk8.4.so"? I'll give your precompiled binaries a shot also.

Quite possibly it's a 64-bit thing as the VM instances I've been testing different operating systems on have been 32-bit. The libtk8.4.so is the correct name - I mistyped it previously.

I've been told that the paths the configure script looks in aren't right for some 64-bit systems though as they sometimes hide the libraries in /usr/lib64/ instead of /usr/lib. I recieved a patch to make this work out of the box without needing --with options (the --with-tklib is confusingly to specify the location of the "tklib" package, not the tk library (libtk8.4.so) - not my choice of words!).

So the next source release should hopefully build better, but I'll try and get a fedora 64-bit install somewhere first to test this. Meanwhile you can either stick with the prebuilt binaries, with their own set of oddities, or if feeling brave try rebuilding the configure script from the m4 files in the subversion repository (http://staden.svn.sourceforge.net/vi.../src/ac_stubs/). I'm happy to send you a locally made configure script too if you don't have autoconf installed.

Sorry about these building problems.

James

[jkbonfield]

So I managed to get gap5 to build and run on a 64-bit Centos system. It did need a patch though to make itcl work (see attachment) due to a non-standard location for it. Sorry I haven't been able to test Gentoo yet.

Centos (and likely some other RedHat based OSes) seem to scatter bits of Tcl to the four corners of the universe, making --with-blah a necessity. The configure line I used was:

./configure --with-samtools=/nfs/team71/psg/jkb/ftp/samtools-0.1.5c --with-io_lib=/nfs/team71/psg/jkb/work/srf/dist --prefix=/tmp/inst --with-tcl=/usr/lib64 --with-tk=/usr/lib64 --with-tklib=/usr/share/tklib0.4 --with-iwidgets=/usr/share --with-itcl=/usr/lib64 --with-itk=/usr/lib64

(The samtools and io_lib bits are just local test installs rather than official locations.) I'm not sure why RedHat uses a mixture of /usr/lib64 and /usr/share for tcl components. Perhaps it's a distinction between packages solely containing interpreted language vs partly or wholey compiled libaries, but tcl doesn't really distinguish this in packages. It's like splitting perl5lib into lots of separate locations. Ugly.

I hope to release a new source tarball soon though with the more up to date configure system. I've put all of these tweaks into the standard configure script with the intention that the next release should automatically build on most standard systems without forcing the user to jump through too many hoops (except for non-standard components like io_lib and samtools).

James

[coldturkey]

Hello

I have not used gap 5 in a while. Has there been any new release or has this project been sidelined? The version I have 1.2.2 does still shutdown out of the blue.

[jkbonfield]

I've just been preparing to release 1.2.4 infact (1.2.3 was in svn but I didn't get around to making a source release). Hopefully it should be on sourceforge by the end of today.

[coldturkey]

fantastic. i look foward to using it

[jkbonfield]

Gap5 1.2.4 (aka staden pkg 2.0.0b2) released

I've just uploaded the latest source tarball for the Staden Package, 2.0.0 beta 2, which includes the latest Gap5. (Infact it's pretty much only Gap5 that has changed since the first beta release, apart from some compilation and configure script improvements.)

Sourceforge RSS feeds are still broken so the staden home page may not update fully. However the direct links are here:

https://sourceforge.net/projects/staden/files/staden/2.0.0b2/staden-2.0.0b2-src.tar.gz/download

I'll add a sourceforge news posting once I work out how best to do it without breaking their RSS feeds even more.

As a comment on the future plans, I hope to backport Gap5 to MacOS X and Windows again once I've stabilised the linux distribution more. It shouldn't be too hard as Gap4 already works on these platforms. Please do PM me or email me with any bugs you get with this release too.

Release notes

Gap5 1.2.4, October 16th 2009

Changes

• Tags can be created and/or removed within the contig editor
  now, rather than just imported.
  
• Gap4's "Sequence Search" function has been added to Gap5,
  allowing for DNA string matches against either the consensus
  and/or the sequences themselves.
  
• Name indexing (tg_index -t) now operates much faster
  (sometimes 100x speed-ups). It also occupies far less space in
  the gap5 database, but note that this comes at a cost of
  incompatibility with older Gap5 formats. (This gap5 should be
  able to load up old Gap5 databases, just not vice-versa.)
  
• (Experimental) The consensus algorithm can now cache the
  consensus, when in read-write mode. This dramatically speeds
  up computing the consensus for subsequent functions at a cost
  of a bit more storage space.
  
• Improvements to the build system, especially on 64-bit
  machines and RedHat derived systems. The --with-iwidgets=DIR
  parameter now has more leeway too and works when given either
  the parent directory or the iwidgets sub-directory.
  "Make depend" is no longer mandatory either.
  
• Tg_index now attempts to automatically work out the file
  format (eg sam, bam, ace, baf, etc). The old "aln" default
  format has been removed.
  
• Tg_index now supports reading sam files provided they have @SQ
  header lines. In addition to this ace, baf and sam files may
  now be gzipped.
  
• Tg_index now has faster read-pairing, using temporary files in
  /tmp. The -f (fast mode) parameter still exists, but should
  not be so significant an improvement now.
  
• Added a "-r nseqs" option to tg_index. This change, which has
  been in the code for some time, but commented out, allows
  tg_index to build gap5 databases in excess of 1 billion
  reads. (The largest here so far was 1.9 billion.)
  Do not use though unless tg_index fails or you are going to be
  indexing a very large genome and need to reserve sequence
  space. See ChangeLog for more discussion on this.
  
• Tags now interpret "\n" as newline within BAF files.

Bug fixes

• Selecting a region in the contig editor that spans a tag no
  longer crashes Gap5.
  
• Fixed a crash when highlighting reading some names in the
  contig editor (buffer overrun).
  
• When exporting to ACE format we now write DS lines again, as
  they're needed by consed. Also fixed generation of BS segments
  when adjoining zero-depth regions.
  
• Export to SAM format should generate better behaved
  flags. Additionally all positions should now be >= 1, even if
  not positioned that way in gap5 itself. (A shift occurs to
  ensure this is true.)
  
• BAF files with blank annotations no longer crash tg_index.
  
• (Plus many minor fixes - see ChangeLog)

[v_kisand]

I just compiled b4 release and it works like a charm,

I was wondering about gap2caf, caf2baf etc. tools. I experience some difficulties in compiling original cap2caf from source code. How one should compile with b4 release?

v.

[[email protected]]

Is it comparative or denovo

Hi,

I am new to all this. Can anybody tell me, STADEN package does comparative assembly or de novo assembly? Thanks

[jkbonfield]

Hi,

I am new to all this. Can anybody tell me, STADEN package does comparative assembly or de novo assembly? Thanks

Hello,

Gap4, one of the tools in the package, does have its own iterative/greedy denovo assembler. However it is designed primarily for small projects (back in the era of cosmid clones and the like). I'd generally recommend use of a dedicated external assembly tool.

Gap5 has no assembly at all except a rudimentary interface to run bwa. I can add other GUI interfaces, but I do not plan on putting a lot of effort into the assembly side of the thing as there are multiple teams of people out there doing this already.

The primary purpose for gap4/5 is to act as an assembly editing and finishing tool, acting at both the micro level manipulating individual bases and/or the macro level of full contig rearrangements - breaking, joining, complementing etc.

[[email protected]]

Thanks for quick reply. I want to do comparative assembly and at the moment using mozaik for that which generates .ace file (.sam & .bam are optional). Can we use GAP5 for viewing, editing and generating concensus sequence from mozaik '.ace' generated file?

Also I want to use some other assembler as well whose output can be input of GAP5. Can you suggest me any? I will be really thankful.

[jkbonfield]

Gap5 can read ace, sam and bam (but gap4 cannot). Most

Note that gap5's ace reading code will yield sequences without quality files, as they are not stored in ace format.

[jensenuk]

tk problem

Hi

I'm trying to install the staden package 2.0.0 beta4. I resolved all dependencies, configured staden with samtools and all additional parameters and installed it typing make/make install. But if I want to execute gap4 or gap5, I get only the following message and nothing else happens:

"attempt to provide package Tk 8.5.2 failed: package Tk 8.5.8 provided instead"

I think just setting some symbolic links will not solve the problem and I have to rollback on tcl/tk 8.4. Is this correct or do you know something else to solve the problem.

Thanks
Jens

[jkbonfield]

I don't entirely understand this.

The staden package uses the system tcl/tk version and on my development machine (an aging Debian Etch system) that's Tcl/Tk 8.4.12. If you've found a dependency on Tk8.5.2 then it's likely to be one of the other packages installed - likely due to Iwidgets.

I have tested it on an 8.5 build when trying installs on other systems, but I forget which specific package versions were installed then.

Can you tell me which OS you're using? While I don't have easy access to reinstall systems, I can run different prebuilt vmware instances (albeit only on my 32-bit desktop).

[jensenuk]

I use OpenSuse 11.0 (i586). But tcl/tk are no system packages. I had to compile them on my own since there was no tclConfig.sh and tkConfig.sh, which are required for ./configure . But probably you're right and it is a dependency between tcl/tk and another package. I hope I will find some time to check this today. Maybe you have an idea what package may cause the problem.