Re: [greenstone-devel] Solaris installation problem

From Katherine Don
DateFri, 28 Oct 2005 16:37:42 +1300
Subject Re: [greenstone-devel] Solaris installation problem
In-Reply-To (43616485-7070709-ucr-edu)
Hi Alain

You could try compiling gdbm in statically. In src/recpt/Makefile, change
GDBM_LIBS=-lgdbm
to
GDBM_LIBS=/usr/local/lib/libgdbm.a
(or equivalent, wherever the gdbm library can be found).
Then run make, make install in the src/recpt directory.

Does it work now?

Thanks for your comments about the install process. We try to make it as
easy as possible for the majority of users to install greenstone (i.e.
windows, linux and mac) and sometimes this means that other platforms
may be a bit more complicated. We don't have any solaris machines here
to test on, so haven't done very much testing for solaris at all.

Regards,
Katherine Don

Alain Veylit wrote:
> Hi all,
> I am trying to install Greenstone on our SUN Sparc machine, running
> Solaris 9. So far, this has been a long series of miseries, but I am
> almost there, maybe...
> The program seems to run OK from the command line, i.e.
> ../gsdl/cgi-bin/library actually produces results, IF the user's
> LD_LIBRARY_PATH environment variable is set to /usr/local/lib. The
> problem is that when I try to access the library program from the
> browser, Apache generates the following error:
> *[Thu Oct 27 16:07:05 2005] [error] [client 138.23.143.201] ld.so.1:
> /res/apps/gsdl/gsdl/cgi-bin/library: fatal: libgdbm.so.3: open failed:
> No such file or directory
> *I tried adding symlinks to libgdbm in /usr/lib and in the apache/lib
> directory, to no avail. I also tried modifying the apache/bin/envvars
> file, and I make sure I set LD_LIBRARY_PATH before I start the Apache
> server as root.
> The error would seem to come from Greenstone, but I think it is set to
> search /usr/local/lib as a default, so it should be able to find the
> library... I tried recompiling with --libdir=/usr/local/lib, that did
> not help. Any suggestions?
>
> Some of the hurdles I went through in the past couple of days:
> The initial Install.sh program refused to go beyond asking me my
> language preference. I ran it as ./Install.sh, sh Install.sh, /bin/sh
> Install.sh, etc. It finally ran with "bash Install.sh" for some reason...
> Then the compilation hit upon a problem with expat and the XML parser -
> it did not help that I have two versions of perl pointing to two
> different c compilers... I discovered the --without-PACKAGE switch in
> configure much too late.... Given that expat and XML::Parser are in
> fairly common use today, wouldn't it be better to just indicate that
> those packages are required and to not include them in the actual
> distribution?
> Some of the Makefiles require explicit /package/expat and/or
> package/cpan links and removing any mention of expat and the XML parser
> is actually quite a bit harder than Greenstone makes it sound on the WEB
> page.
> Also, I had to copy manually the expat_external.h file to the include
> path. I am not sure why.
> Sorry to sound grouchy on my first message to the list. I am not trying
> to blame anyone, but perhaps some of the details from my own experience
> will be helpful to others and save them some time.
> Alain
>
>
>
> _______________________________________________
> greenstone-devel mailing list
> greenstone-devel@list.scms.waikato.ac.nz
> https://list.scms.waikato.ac.nz/mailman/listinfo/greenstone-devel
>
>