Please bear with us in reading what is a rather long email communication.
We wanted to summarize as clearly and completely as possible the history
of our experiences trying to install and use Greenstone. First let it
be said that we, being part of a R&D group, fully understand the time and
effort it takes to create and distribute such a package. We also understand
that you can not put yourself in the position of providing serious ongoing
support of the form one might expect from a commercial firm. We deeply
appreciate the kind help of Stefan Boddie in response to our email queries.
We support the open source movement, and think it marvelous that you have
released this substantial effort to the computing community. We are
enormous admirers of the publications and code that have come out of this
group in the past ("mg" prominent among them). The Greenstone system
looks very promising, and we have been highly motivated to get it up and
explore its use. However, we have been working on it for four releases now
(2.31, 2.35, 2.36 and 2.37), starting in May 2001, and have sadly come to
conclude that we must draw a line under our efforts. This communication is
sent in the hope that we might, with once last effort, succeed in making
the system work. Otherwise, we will, with much sadness, have to put it
aside and consider our efforts with it to have been a failure.

We use Sun SPARC platforms running Solaris 2.8; we have both gcc 2.95.2
and 3.0 available (as well as Sun's commercial C compiler, which we rarely
use). Virtually of the important GNU tools are also available. We employ
the depot convention for the management of network-shareable locally installed
software (depot has been around for > 10 years in the UNIX community; we
attach an article we presented at the last USENIX/LISA conference about some
work we have done with it). Local software appears not in /usr/local (which
does not even exist on our machines) but in /depot/bin, /depot/lib, /depot/man,
....

Here is a highly condensed summary of our installation history with
Greenstone:

Version 2.31:

We downloaded the UNIX binary distribution. The script "Install.sh" failed,
and as a result we had to modify the supplied configuration file.
The installation process made assumptions in multiple places about
local software being in /usr/local. The installation instructions did
not specify the use of GNU (as opposed to the Sun-supplied) version of
make. We got stuck at the point that it tried to install wv; we removed this
package from the PACKAGEDIRS list and reconfigured/recompiled, only to
get stuck at another package, whereupon we were advised by S. Boddie
to move to version 2.35.

Version 2.35:

We observed the following:

[...]
--> Install.sh: [cd /depot/package/greenstone_2.35/gsdl]
configuring ...

--> Install.sh: [./configure]
loading cache ./config.cache
./configure: USE_CORBA=0: is not an identifier
compiling ...

--> Install.sh: [make]
make: Fatal error: No arguments to build
installing ...

--> Install.sh: [make install]
make: Fatal error: Don't know how to make target `install'
--> Install.sh: [cd /site5/SOURCE/INSTALL/greenstone_2.35.dir/gsdl-2.35-linux/Unix]

ERROR: Compilation failed
Greenstone was not installed successfully

Several months after an email report on this set of problems, we were
advised by S. Boddie to move to version 2.36.

Version 2.36:

Given our history with the automated installation system, we downloaded the
source (rather than binary) distribution, and manually compiled all the
packages and installed Greenstone. This was highly non-trivial given the
meager documentation on building from source, but we proceeded with kind
help from the Greenstone mailing list and S. Boddie. We also had to learn
via email from S. B. as to how to set the administrative password and
properly set permissions for gsdl/etc/*, gsdl/tmp, and gsdl/collect
(which were not otherwise documented). We still could not log on,
and after three more email exchanges (with helpful additional information
from S.B.) we finally were able to log on. But we still could not create
a collection. Here is a pithy summary of the final problem list:

1) Can not create a collection unless logged in as admin (quite likely
normal, but the document does not make this clear and we never
received confirmation in response to our email query).

2) During the fourth "Configure collection" step, the text area for
the configuration file display is empty (abnormal according to document).

3) During the "Building" stage, we observed the following error message:

An error has occurred while attempting to build your collection.
The build log contains the following:

copying /depot/package/sam_4.3/pdf/sam_4.3/sam.pdf -->
/depot/package/greenstone_2.36/vendor/tmp/tbuild3/test/import/depot/package/sam_4.3/pdf/sam_4.3/sam.pdf
importing the test collection
No plugins were loaded.
build: ERROR: import.pl failed

Obviously, the system could not find the plugins it required, even
though we had properly set gsdlhome in the file gsdlsite.cfg as
instructed in the documentation.

4) The demo collection icon does not appear on the Greenstone home page.
To create the demo collection, we ran the appropriate Greenstone
executable, as instructed in the installation document:

[...]/cgi-bin/library

Resulting in:

Collections:
------------
Note that collections will only appear as "running" if
their build.cfg files exist, are readable, contain a valid
builddate field (i.e. > 0), and are in the collection's
index directory (i.e. NOT the building directory)

demo public not running
WARNING: No "running" collections were found. You need to
build one of the above collections

We inferred that this occured because the file
$GSDLHOME/collect/demo/etc/collect.cfg was empty, and tried to
manually create such a file by executing "mkcol.pl". Then we
tried to import data by using command "import.pl demo", which
resulted in voluminous output of the form:

RecPlug: getting directory /depot/package/greenstone_2.36/vendor/collect/demo/import
[...]
doc::_calc_OID /depot/package/greenstone_2.36/vendor/bin/SunOS/hashfile could not be found
BASPlug: WARNING: language/encoding could not be extracted from /depot/package/greenstone_2.36/vendor/collect/demo/import/index.txt - defaulting to en/iso_8859_1
[...]
HTMLPlug: processing faobetf/fb34fe/fb34fe.htm
doc::_calc_OID /depot/package/greenstone_2.36/vendor/bin/SunOS/hashfile could not be found

Then, out of curiosity, we tried to build a collection using the
data from the preceding (failed) step using "./buildcol.pl demo":

*** creating the compressed text

collecting text statistics
Uncaught exception from user code:
mgbuilder::compress_text - couldn't run
/depot/package/greenstone_2.36/vendor/bin/SunOS/mg_passes
mgbuilder::compress_text('mgbuilder=HASH(0x13d8bc)', 'section:text') called at ./buildcol.pl line 279
buildcol::main() called at ./buildcol.pl line 43

whereupon we observed that the directory:

/depot/package/greenstone_2.36/vendor/bin/SunOS

does not exist. We never received replies to our queries about this
problem, nor about how (or if) Greenstone cleans up the files it
places in its tmp directory.

After sending numerous queries to the mailing list, we decided to try to
install 2.36 using the binary packasge, but repeated download attempts revealed
that the file on the originating site was corrupted. Therefore we moved
to the latest (2.37) release.

Version 2.37:

We tried to install the binary distribution. The script "Install.sh" failed
again. There were several difficulties:

1) GNU make is used to compile all the package, but the documents still do
not make this clear (fixed in our case by prepending PATH with "depot/bin").

2) In the file src/Unix/configure, GDBM_LIBPATH and GDBM_INCLUDE are hard-coded
so as to look for software in /usr/local. We had to manually edit this
file to change these variables.

3) We use gcc 3.0 as our compiler. The environment variable "CC" did not get
passed down to the rtftohtml package build, and it kept trying to use the
(nonexistent) "cc" command, causing failure. We had to modify
src/package/Makefile, adding an extra variable "MDEFINES" to pass
"CC=gcc".

4) In directory src/mgpp and lib, incorrect header files were included because
constants were not defined during configuration. For example, in the file
lib/text_t.h, the correct header file set is that which is associated with
"GSDL_USE_STL_H" being defined, but it was not so defined:

[...]
#if defined(GSDL_USE_OBJECTSPACE)
# include <ospace\std\vector>
[...]
#elif defined(GSDL_USE_STL_H)
# include <vector.h>
[...]
#else
# include <vector>
[...]
#endif
[...]

Conclusion

This is a heavily distilled summary of the large number of interactions we
have had over the past months with respect to Greenstone. We hope that
this note and the history behind it make it clear that we have more than
a casual interest in Greenstone, and have made a serious effort to build it,
expending many hours of our time.

Given our experience, though, we find it difficult to believe that anyone
has successfully built and operated this package under Solaris using gcc.
We have seen only one posting to the mail list from another Solaris site,
and that one was reporting problems with installation. We are still
very interested in installing and using the system, but are at wits end.
The package is complex, and we can't really hope to succeed with it without
closer colaboration with the development team, or at least with another
site that has successfully installed it in a similar environment. The
supplied documentation is insufficient to install the system, the
problems we have pointed out in the past have not been addressed, and
although we appreciate S.B.'s periodic replies to our email queries, the
final advice has consistently been to "move to the latest release,"
which has never advanced the effort. (We would be happy to supply copies
of all past email and mail list postings if it would be helpful).
We send this summary as one last effort to see if we can interact with you
in such as way as to get Greenstone working under Solaris/gcc, which we
think would be of great interest, as this platform is widely available in
the academic, research, and library R&D communities. In any event, we
thank you for your past help and wish the Greenstone project and its
follow-ons the greatest possible success...

Thanks and Best Regards,

Rick Rodgers (rodgers@nlm.nih.gov)
Ziying Sherwin (sherwin@nlm.nih.gov)
--------------------------------------------------------------------------------