In article <learn-2710971003180001 at tench.microbiol.washington.edu>,
learn at u.washington.edu (Jerry Learn) wrote:
> Do you have a list of the changes to the Makefile, or possibly the
> Makefile itself that you could send to me? I would very much appreciate
> it. I would be nice if someone could find a computer science student to
> rewrite treetool in Motif (although I still like OpenWindows). It is, in
> my opinion, the best program for manipulating phylogenetic trees, although
> it does have a few quirks that I'd like to see fixed. At least it doesn't
> crash the Xwindows display like it would frequently do under Solaris 1.
The 'Makefile' for 'treetool' is pretty simple and doesn't need any
changes. It comes with 'gcc' as the default compiler and that's what I've
used (I'm, still on gcc 2.7.0, but should upgrade); the newer
ANSI-compliant SparcCompiler would probably work but you would need to mess
with the 'Makefile'. Also the '-traditional' compiler flag is essential
because the 'treetool' code is not ANSI compliant; you will still get
warnings but apparently none are serious because the resultant 'treetool'
binary seems quite stable.
I have made 6 changes to the 'treetool' code to compile it; half of these
are actually replacing old BSD functions with the SYSV counterparts.
Although you could probably get these working as is, by adding a few
includes and the appropriate library using so-called BSD-compatibility, I
decided to simply update them because it is pretty trivial. In the Solaris
2.4 man pages Sun strongly recommends against using such BSD functions as
'gethostname', and the old 'strings.h' versions of 'index' and 'rindex', on
non-BSD systems (in other words Solaris 2.x).
First: in the 'graphics' subdirectory, in the file 'pdraw.c', add the line
'#include <sys/systeminfo.h>' to the headers; replace line 280(+-) that
reads 'gethostname(hostname,40)' with 'sysinfo(SI_HOSTNAME, hostname, 40)'.
Second: in the subdirectory 'treetool':
In the file 'load.c', make sure you have the header 'string.h' rather than
'strings.h' at the top; on line 93 replace the function 'index' with
In the file 'misc.c', check for 'string.h' as above, and replace the
function called 'rindex' on line 14 with 'strrchr'.
In the file 'print.c' on lines 37, 39, 41 which include the command 'lp',
add the option/flag '-c' after each 'lp' (with appropriate spaces of
course). This solves an annoying printing problem which is caused by the
spooled temp file for printing being deleted right after it's created,
which confuses the print daemon a bit.
In the file 'size.c' on line 422 the function 'sincos' is no longer
available. Replace this one line with:
's = sin(a)';
'c = cos(a)';
In the file 'treedata.h' on line 342 change the line 'selection_type
clip_type' to 'selection_type *clip_type'. This really only eliminates a
compiler error and this variable is never actually used so the line could
be cut out, if you cut out another (useless) reference to 'clip_type' in
I could have incorporated this in a 'diff' file but I don't have the
original files any longer, and I couldn't be bothered.
Also I must mention that in a previous post when I was raving about not
being able to build 'treetool' under LINUX because of a Sparc-specific
static library, I was confusing 'treetool' with the multiple alignment
editor 'ae2', which does come with such a library, I'm positive, I think.
However, although I have built 'treetool' at home under LINUX (XFree86 3.3,
Redhat 4.2, kernel 2.0.30), the program always blows up at launch with the
dreaded colormap errors, regardless of whether the X server is in 8, 16 or
24 bit mode. I intend to try to resolve this although 'X' is not my
specialty by any means.
I agree that 'treetool' is probably the best tool of its kind at this time
that I'm aware of, and I think I've tried them all and for all major
> About GDE, have you fixed it so that the meta-keys work? That's the only
> feature that I miss in the version that I use (ported to Solaris 2.x by RZ
> and NJP). Meta-g and meta-n work but that is it. Also under Solaris 2.x,
> the edit window "grabs" the focus in a very inconvenient fashion. If a
> dialog window opens over the sequence part of the edit window, I can't
> point to it without having the edit window jump to the top. Does your
> build have that same problem?
The meta-key mapping in GDE is a real mess and doesn't work on any version
I've built myself. I looked at the code, the functions are defined in
'Builtin.c' and called from 'Edit.c', but I haven't found a solution yet
and the code for these is a bit weird. The only meta key that works for me
in GDE (other than the system meta-q and meta-w) is meta-N; it is defined
in the configuration file '.GDEmenus' and that may have something to do
with it. On the other hand the version of GDE I built for LINUX (XFree86)
really doesn't like the meta-key mapping code; GDE blows up as soon as you
touch the "meta" key ('Alt' on my PC keyboard). That does suggest some
I have used a version of GDE that doesn't have the fouled up mouse focus
problem you mention, but I can't remember whether it was one of my versions
or the available binary called '2.3-NJP+RZ'.
David F. Spencer, PhD
Dept. Of Biochemistry
Halifax, Nova Scotia
dspencer at is.dal.cadspencer at rsu.biochem.dal.ca