You downloaded the source files, like I did, but you need to compile them to binaries for actual use.
I have the staden-1.6.0 already installed, so I don't think I need to worry about the external packages (right?). Even so, when I tried to 'make' I got the following:

In the 2004 README.build file that comes with the source files, it says that "To compile the code and docs just type "make" and let it get on with it.". I had followed the other instructions, such as changing .bashrc to alter stadenroot to the new directory of the 1.7 version, but I can't get past the above errors. A binary for macosx would help a lot, but this error should also be easy to fix.
MDS

A couple of comments regarding several points in this extended thread about Staden on Mac OS X.
I haven't attempted to get 1.7 built for Mac OS X recently (will try again today maybe) but as anyone who had tried to build usual, "generic", C code for this environment knows, Mac OS X is a lot harder to get things compiled properly than on general linux/unix OSs.
For all platforms it is critical (in both installing a prebuilt binary distro or building Staden from source) to get the 'staden.profile' run before trying anything else. One of the critical environment variables set in 'staden.profile' is that of 'MACHINE', and that is what is used to determine where in the staden subdirectory (normally in '/usr/local/bin') the critical files are kept. So, for example, the actual binaries are in $MACHINE-bin (where $MACHINE will be 'linux' for the distributed linux-x86 Staden package) and in 'lib' the libraries are in $MACHINE-binaries. When you build Staden, there are two 'mk' files sourced, one 'global.mk' and one specific for the OS you're using (so for example 'linux.mk' or 'solaris.gcc.mk' for Solaris on SPARC using gcc'). The 'staden.profile' script assigns the MACHINE variable by running the linux/unix/bsd utility 'uname', with the options '-srm'. However, in Mac OS X 'uname' never gives a response that has 'MacOSX' (or any variation of that) in the output because Mac OS X is really at its core called 'Darwin'. The 'staden.profile' script uses the response 'Darwin' to assign 'macosx' to MACHINE, but I recall just hard-coding MACHINE when working with Staden on my Macs, I assume because something didn't work.

There was also an issue here about Fortran code in Staden and the need for Fortran libraries (as well obviously as a Fortran compiler). I can find only one piece of Fortran source in Staden, 'legacy.f' in the gap4 source, but included with this file is 'legacy_f2c.c' which is 'legacy.f' run through the utility 'f2c' to convert the Fortran to C. On most builds the file 'legacy.f' is not compiled (and that includes macosx, but strangely for linux it is used). So in the final linking the library you need is actually 'libf2c.a', invoked in Makefiles as '-lf2c -lm'. I would expect that even for Leopard (which I am not using) you could find that library somewhere on the net and build it yourself.

I have recently been fighting to get a 64 bit version of Staden 1.7 compiled for AMD64 PCs, and I am confident that the Mac OS X process will be an even greater challenge.

We've built 1-7-0 on a Mac and it appears to work OK. It was built with a later version of io_lib and I'll have to check to see which one. I'll try it out on the course data and if it works I'll see if I can bundle it as a Mac app and you're welcome to it (with all the standard boilerplate releaving me of responsibility if things go horribly wrong... ;-) )

I'm happy to host a MacOS X build of 1.7.0 if someone else is willing to build it. I simply haven't had time to build for all platforms, but I also appreciately it's not trivial to build from source either. Sorry. Please mail me direct if you're willing to help with this.

For reference, to build you need to set STADENROOT environment and source the staden.profile (or staden.login if a csh user) prior to building, then the ".mk" issue will go away. You'll also need a variety of third party libraries installing (see Makefile.thirdparty). Some may not be vital if you have versions already installed, but I couldn't vouch for compatibility if you use a different version of the libraries.

I got the source version and the latest version of io_lib. I did all the preliminary setup with STADENROOT and staden.profile. I built and installed the updated version of io_lib. I built the thirdparty libraries. At that point, I just started changing the makefiles in the staden package to fix the build errors. One of the first and most pervasive is the -bind_at_load (not sure of the spelling here) that is included as a loader flag. It's for libraries only, but it gets used to link executables and causes the links to fail. As for the rest, I just kept tracing the errors back to the makefiles and changed the makefiles to get to the next step. Eventually it all built and at least pregap4, gap4, and trev work OK. Unfortunately I did not write down each and every change but it would be easy enough to download a fresh copy and do a diff on the makefiles to recover what I had to change. Note that I changed the makefiles themselves and not the inputs to automake which is strongly discouraged, but I did it anyway. I'm a little more comfortable now with automake and if I had to do it over I'd do it correctly.

I also built the 1.7.0 package on a linux box and experienced many of the same problems so they are not all unique to the Mac. I believe that it's acknowledged that enough time has gone by such that new versions of libraries and make tools have created incompatibilities.

I will see what I can do to prepare an installable package of the binaries and/or a release that will build on the Mac.

I'm working on a macport of Staden. I have run into many problems and fixed a lot of them, but I'm fairly stuck at the moment. Among the major patches I had to make were to remove the -bind_at_load flag from linking, add -single_module and add some library paths. I added the -single_module flag because of multiple definitions in linked libraries causing libtool to bomb. I read this in a forum, not sure if it's the right thing to do.

The problem now is that some of the libraries depending on other shared libraries are expecting them to be in a path relative to where they were built, i.e. one directory more up from lib/macosx-aqua-binaries. This is silly, of course, but it makes me wonder about my linking strategy. I don't think I've had to link shared libraries that depend on each other (that haven't already been installed, so the paths are correct), so I'm not sure if I would know what to do.

Anyway, I'm wondering if you can provide a patch between 1.7.0 and your makefiles/dependencies, etc., so that I might get an idea of how I might fix these problems. Since macports are quite compact, this is a good thing to keep around, because they can potentially guide building in future releases (should they come).

I used a brute force approach to missing libraries. I used 'locate' to find the library (building it if necessary) and I put a link to the library or the library itself where the make script expected it. It's ugly but it works and I haven't yet figured out all the details of the make file structure.

I will try to get the binaries or a working build system posted as soon as I can. I have working binaries but I haven't had a chance to test them outside of the build tree. I try also to build a patch set for our local make files.

Is that the bind_at_load error you were mentioning? Unfortunately, I really have no idea what the -lF library is supposed to be referencing, as I already have the external dependencies mentioned in the README.build (from the Makefile.thirdparty).
I don't know if it makes a difference in this case, but I'm on 10.5.1.

It appears as if the Fortran libraries shipped with Leopard are incompatible with a number of compiles and programs, not just Staden. There are a number of workarounds, but I think for now I will stick with 1.6.0 and wait for a proper fix.

It should work out of the box as a 64-bit version, but possibly that's only in the CVS tree. I did think even 1.7 worked though. (We pretty much exclusively use 64-bit AMD systems here.) I guess I ought to package up a new release sometime.

As for the Mac version, hopefully with Mike's help we'll put a MacOS X bundle on the download page at some stage.

I am interested in installing Staden on Mac OS 10.5 and I would like to know if the Mac version has been completed. I saw that a PowerPC version exists, but will this work properly on Intel based systems?

I downloaded the 1-7-0 version of the staden package yesterday, and apart from a minor issue of the iwidget directory being a symlink to "/Users/jkb/src" (fixed by creating an actual iwidget directory and copying iwidget.tcl from elsewhere into it) all appears fine (macosx 10.5, mac pro). All the programs I've tested display their usage messages when run with no input, but when I tried to use makeSCF and convert_traces they both output messages declaring they can't read the input file, or couldn't read stdin in convert_traces' case (including the .ab1 file in the userdata directory of the package). Is this because I don't have a license file? Or is there some unusual path issue involved?

Help would be greatly appreciated, I just wanted to use makeSCF or convert_traces to convert some abi files to scf initially (and gap4 later).