These notes were written for gsdl-2.39, but probably apply to other versions as well. You might find a more up-to-date version on-line at http://www.greenstone.org/docs/compiling.html. Greenstone version 2.39 was released on the 10th March, 2003.
(we include cygwin here).
The "standard" commands of$ ./configure $ make all $ make installshould (hopefully) be all that is required. Currently, Greenstone does not honour the `--prefix' flag, but the directories are self-contained, so should be able to be moved after installation.
You will probably need to use GNU make.
Version 2.38 of Greenstone compiles with gcc version 3.0 (as well as earlier versions of gcc). Earlier versions of Greenstone will require earlier versions of the compiler -- we have successfully used versions egcs-2.91.66 and gcc-2.95.
The Greenstone Librarian Interface (GLI) code is written in Java, and compiling it requires a suitable version of the Java Software Development Kit (version 1.4.0 or newer). To compile this source code, run makegli.sh from the gsdl/gli directory.
isis-gdl/CRC32.cpp isis-gdl/IsisTypes.h isis-gdl/Master.cppIf you copy these over the 3 files with the same name in gsdl/packages/isis-gdl then it should all compile ok with gcc 3.
The GDBM library and headers are needed - Linux distributions typically come with the library, but may or may not come standard with the header file. Darwin does not come with either. If it is not installed in /usr or /usr/local then you will have to specify where it is by using the configure flag --with-gdbm=/path/to/gdbm/dir.
The GDBM library can be downloaded from ftp://ftp.gnu.org/pub/gnu/gdbm/gdbm-1.8.3.tar.gz or a closer mirror.The following configure flags add extra functionality to Greenstone:
--enable-corba | Creates a CORBA server as well as the .cgi server. This is currently
still developmental, and compilation hasn't been tested on many
platforms. A java CORBA client is available through anonymous CVS
(password anonymous) -
export CVSROOT=:pserver:[email protected]:2402/usr/local/global-cvs/gsdl-src cvs login cvs export -r HEAD java-client |
--with-micodir | Use an existing MICO compiler for the CORBA server instead of compiling our included version. |
--enable-z3950 | Enable rudimentary Z39.50 client support in the .cgi server. |
Also some of the third-party packages required some manual attention.
Make sure you have the gdbm package installed.
All compilation is currently done through a terminal.
Note that the default filesystem is case-insensitive.
Mac OS X uses a compiler based on gcc version 3, so read the above section on Unix Compilation Notes for changes required to the source code for greenstone version 2.41.
darwin doesn't come with gdbm, so:
FontFile.h:27: storage size of `_ZTI8FontFile' isn't known FontFile.h:46: storage size of `_ZTI13Type1FontFile' isn't known FontFile.h:67: storage size of `_ZTI14Type1CFontFile' isn't known FontFile.h:144: storage size of `_ZTI16TrueTypeFontFile' isn't knownThe work-around is to remove all lines with "#pragma" from the source-code of the pdftohtml package. See the bug report on pdftohtml's site. This will be fixed in Greenstone version 2.39 and later.
As mentioned above, version 2.38 of Greenstone compiles with gcc3. If you are using an earlier version of Greenstone, you will need to make sure you are using an older version of gcc, and not gcc2.96 or gcc3. Red Hat >= 7.0 comes with the newer versions of gcc by default.
You will need the gdbm.h header file. If you don't already have it, it is in the libgdbmg1-dev (debian) or gdbm-devel-1.8.0 (rpm) package.
We have had a couple of reports from SuSE users that one of our third-party packages (wget) fails to configure as it uses GNU msgfmt for translation catalogues - this is resolved by installing the gettext package. This seems to be already installed on other distributions.
Alpha architectures:
Well, the good news is that it compiles OK (for versions of gsdl >= 2.37
- earlier versions need updated config.sub files),
the bad news is that it fails to build collections. One possibility is that
mg (the backend code) doesn't like the 64-bit ints.
We no longer have solaris machines running in our department. However, Greenstone built and ran the last time I could log on (about version 2.33?), and we have reports of people getting current versions working, with minor changes.
Greenstone includes a perl module from CPAN, XML::Parser (+Expat), which has caused problems on some machines during the make. This is because perl uses it's own config file to get compiler settings, etc. We think we have worked around this. If you get compilation problems, you can do one of the following:
You might need to manually install the gdbm library, and you probably
need to use GNU's make. try setting the MAKE variable when
you run the configure script, such as:
$ MAKE=gmake ./configure [options]
or
$ ./configure [options] ... $ gmake all
We have tested with versions 4.2 and 6.0. Our distribution includes a cut-down port of the gdbm library for windows.
We compile Greenstone from the Windows command prompt. You must manually unzip files in the gsdl\packages\crypt and gsdl\packages\gdbm directories. After setting up the VC++ environment, simply type nmake /f win32.mak and everything should compile OK. For us, setting up the environment requires running the vcvars32.bat script, found in the VC++ installation directory (for us this is in C:\Program Files\Microsoft Visual Studio\VC98\bin.)
The third-party packages (pdftohtml, wvWare, rtftohtml, xlhtml, etc) were compiled using cygwin.
The Greenstone Librarian Interface (GLI) code is written in Java, and
compiling it requires a suitable
version of the Java Software Development Kit (version 1.4.0 or newer).
To compile this source code, run makegli.bat from the
gsdl\gli directory.
64 bit processors
John has tried once to compile Greenstone on a 64 bit processor (Opteron, Amd64) running 64 Ubuntu. He reported several problems which are listed below. These have yet to be resolved.
1. When trying to build anything using mg (i.e. mg_passes) I'm suffering a seg fault somewhere deep in the malloc code (mallopt). From what I can tell the mg stuff uses some library wrapper (gsdl/packages/mg/lib/memlib) which has some prototypes which override the stdlib.h ones. If I let them do this, I believe malloc might be using 32 bit ints to hold pointers (which are 64 bit under X86_64 architecture). If I prevent memlib overriding by setting the STD_MEM precompiler flag I get a bazillion warnings - and it still seg faults in the same place (again implying a pointer != int problem).
Below is a dump of the error messages I encountered when trying to debug the malloc problem.
(gdb) file /var/www/projects/john/gsdl/bin/linux/mg_passes (gdb) run -D -f /var/www/projects/john/gsdl/collect/demo/building/text/demo -b 12000 -T1 -M 4 -d / < /tmp/output.txt (gdb) backtrace #0 0x0000002a95c7bab6 in mallopt () from /lib/libc.so.6 #1 0x0000002a95c7aa63 in malloc () from /lib/libc.so.6 #2 0x0000000000402bf5 in process_text_1 () #3 0x0000000000401fb1 in driver (in_fd=0, Trace=0x0, file_name=0x7fbffffb5d "/var/www/projects/john/gsdl/collect/demo/building/text/demo") at mg_passes.c:336 #4 0x0000000000402617 in main (argc=11, argv=0x7fbffff918) at mg_passes.c:626
2. When trying to search a collection which was imported/built using mgpp I get this cool error message:
Couldn't load index information for "idx"
and no results. Strangely enough browsing works just fine. I tracked the problem back to the loading of the index files in (gsdl/src/mgpp/text/IndexData.c) and in particular these lines
// blocked dictionary ... fseek (dictFile, bdh.wblk_idx_start, SEEK_SET); if (!ReadBlockIdx (dictFile, biWords)) { UnloadData (); return false; } ...This always returns false. So the fseek to the start of the dictionary is failing. Weird eh? Any ideas? Currently I suspect a bogus pointer to int cast somewhere in the mgpp code during import/building is resulting in an equally bogus index file.
3. So... believing I didn't have quite enough problems to sort out I attempted to fix the second problem and thus created another wonderful problem. Whenever I browse to my custom collection I get the "Opps! An error occurred..." page - but with no error message. However if I run the binary from the cgi-bin it works just peachy. It sounds like a permissions problem - but it isn't. I've triple checked all the permissions. Running the plain-jane greenstone library, then going to the custom collection works just fine (bar the searching problem outlined above).
Contact Us
If Greenstone doesn't work for you, please let us know! If you add information such as operating system and software tool versions to your request then it will help us to fix the problem.
If you have any updates or corrections to this documentation, then don't hesitate to send them to us.
Send mail to us at: greenstone@cs.waikato.ac.nz.
We also have 2 mailing lists, one aimed more at users and the other aimed more for developmental issues. You can subscribe by going to https://list.scms.waikato.ac.nz/mailman/listinfo/greenstone-users and/or https://list.scms.waikato.ac.nz/mailman/listinfo/greenstone-devel. Archives are available (using Greenstone of course!) at http://www.nzdl.org/cgi-bin/library?c=gsarch&p=about.
Last modified 20 April 2004 by John McPherson