|Many thanks to Katherine and Kurt for a prompt response:
I tried Katherine's suggestion and recompiled with gdbm in static mode.
That did not work.
I tried Kurt's suggestion of wrapping the library program in a script,
that did not work either, although Kurt's problem sounds very, very
close to my own.
The solution that worked was to add (numerous) soft links in /usr/lib to
the libgcc_s.so and stdlibc++.so libraries in /usr/local/lib.
-Should I have used a "-I/usr/local/lib" directive in configure to make
all this easier?
-Is it possible that my problem comes from a confusion between gcc and
the SUN native compiler?
-Should I recompile with the original dynamic gdbm configuration?
-Would Solaris 10 have proved less problematic? I think they tried to
make it LINUX compatible...
The main thing is that I made it passed the installation stage (I think...)
So thanks for your hard work and help,
Katherine Don wrote:
>You could try compiling gdbm in statically. In src/recpt/Makefile, change
>(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.
>Alain Veylit wrote:
>>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 126.96.36.199] 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
>>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
>>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.
>>greenstone-devel mailing list