Hello Greenstone Developers:|
interest of perhaps helping the next fellow down this particular road
(Greenstone on Solaris), what follows is some of the pitfalls and
solutions that we have found during the installation on Solaris.
Much appreciated has been the help from John McPherson, who created an
updated configure for our use and has managed to answer our questions, or
at least point us in the right direction.
Perl had already been installed on our box when we started, so we needed
to add Gnu C and C++ with Libs, Gnu GDBM, Gnu make, and libiconv.
We used the
site to retrieve the following ".gz" files and used
"package add" to install.
(after 3.4.2 was a problem with another application)
that the libraries are installed with these (libgcc-3.3
downloaded and "untared" the greenstone source, we attempted to
use configure. We encountered a syntax error in config.cache.
We could get around this error using ./configure --cache-file=/dev/null,
but we opted to try to fix the problem. John suggested we try
to build a new configure with a current autoconf, so we downloaded the
autoconf and automake from the sunfreeware site, attempted to build a new
configure, but ran into an old feature (LIBOBJS) in the configure.in that
needed to be upgraded. (John created a new configure for us to use,
so it may be available in the current download at this time, so you may
not encounter this problem.)
necessary to add to PATH /usr/local/lib and /usr/local/bin. I put
them first since I wanted to be sure to get the Gnu versions. Also
needed is the setting the LD_LIBRARY_PATH to include /usr/local/lib and
possibly /usr/local/include. Configure now worked with the command
./configure CC=gcc CXX=g++.
failed. The compile died on variety of wide-character
functions. We were stumped by this one for awhile, especially when
we were informed that Greenstone was not using any of these
functions. Turned out that another application (MYSQL) would not
work with the current libgcc, and since this can be downloaded separately
from gcc, that is exactly what happened, overlaying the current version
(oops). We ended up with a current version of gcc and an
older version of libgcc. Once the versions were the same, the
compile problems went away. We also had to configure with
"--with-libiconv=/usr/local/lib" and make libiconv in the
local directory, for some reason, it would fail from the higher
level make. The command "make CC=gcc CXX=g++" now
a couple things that needed to be done at the top level make for the
install portion. The section of code that follows needed to be
commented out in the default Borne shell - it dies - since the loop is
There is nothing in MODULEDIRS.
for odir in
$(MODULEDIRS); do \
making $@ in $$odir; \
$$odir && $(MAKE) $(MDEFINES) $@) || exit 1; \
oaiserver file was not in the cgi-bin directory, so I created an empty
file so the install command would move the file. The "make
install" now worked.
step was to copy all the code to where it would reside in production
environment. The Greenstone library executable in the cgi-bin
directory needs libstdc++.so and libgcc.so located in
usr/local/lib. By default, when launched as a CGI the application
will search usr/lib, but not usr/local/lib. Currently, there is a
link in usr/lib pointing to usr/local/lib. We are looking for a
better way to do this.
thing to check is the permissions on /etc/users.db - if not writeable,
greenstone will fail to log you in as admin/admin.
Hope this was helpful.