I downloaded gsdl 2.31 Linux source, as well as all the manuals and while ./configure and 'make' worked fine, Install.sh does not work correctly, evidently expecting a different directory structure than the one in the tar.gz file.
'make install' seemed a bit different from what I would expect as well, since it did not copy to /usr/local/.... but rather to other directories in the build directory. Even after doing this, Install.sh did not work.
The error is: 'could not locate /tmp/Unix/bin/linux'. Even if I could get by this, Install.sh seems to want to copy all the contents of the build directory to /usr/local/gsdl, which would include all source code and compiled executables. Later copy commands for setup.xxx also refer to directories that do not exist. I guess I would expect all the cgi-bin executables, macro's and perl scripts to be copied to /usr/local/gsdl, but not the actual C++ source.
I think Install.sh is set up to work best on a cdrom image containing prebuilt Linux binaries, even though it has an option to recompile source code.
I have seen great comments about how easy it is to install using Install.sh, so I am worried that I did something wrong.
While I could probably puzzle out what I need to copy in order to install gsdl myself from reading the Install.sh, my comfort level would be higher if an automated script could deal with it.
FWIW, I downloaded the source tar.gz to /tmp and untarred with tar -xvzf gsdl-2.31-src.tgz, then 'cd gsdl', './configure --enable-z3950', 'make' and everything built fine.
I think that the problem here is that Install.sh
needs to be run from the directory that it is in - eg /cdrom or /mnt/cdrom. Looking at the script, it
looks like it assumes that this is the case.
Since you can't be default run executables from
the cdrom in some distributions, the safest way
is to 'cd' to the mounted cdrom dir, and type
"sh -c ./Install.sh". Of course, if you're comfortable with ./configure and make, you could
just do this yourself.
The configure script does the same - assumes it is
run from it's own directory.
I agree that ideally you should be able to run
them from anywhere, this may (or may not:) be fixed up at a later stage.
Thanks for the feedback,
I guess I did not make myself clear,
1. I downloaded the source tgz file to /tmp. I do not have a cdrom of greenstone.
2. uncompressed/untarred it, which created /tmp/gsdl/ with many files and directories in it, among them Install.sh in /tmp/gsdl.
3. In /tmp/gsdl I ran ./configure --enable-z3590, then ran make, which built the binaries.
4. WHILE IN /tmp/gsdl I ran .Install.sh, which gave me the errors I listed.
No where in the directory structure I downloaded is there a Unix directory as the Install.sh requires. I think this only exists on the CD-ROM or in the Linux binary distribution, which I did not want to use because I have less trouble with software I compile from cource in many cases.
I later went ahead and downloaded the binary tgz as well and rebuilt the executables from there using Install.sh.
You're quite right that Install.sh is designed to be run only from a cd-rom distribution or the linux binary distribution (which both have a different directory structure from the source distribution).
In fact, much of what Install.sh does involves creating a directory structure like that used by the source distribution. Therefore, to use the source distribution you should simply unpack it to the place you want Greenstone to live (e.g. /usr/local) and do a standard "./configure", "make", "make install" from there.
This points out a problem with the naming of our distributions that I've been planning to fix for some time. That is, as you discovered, the linux binary distribution also contains the source code and can be installed using Install.sh. It just happens to contain some pre-compiled linux binaries too. People like yourself who want to compile the software themselves tend to opt for the so-called "source" distribution though when they would be better off with the badly named "linux binary" distribution instead.
I imagine that when I get around to it I'll either
a) do away with the current "source" distribution and rename the linux binary distribution to something like the "unix" distribution.
b) alter the "source" distribution so that it's very much like the current "linux binary" distribution but doesn't contain any pre-compiled binaries.
c) leave things much as they are now but rename the various distributions and try to make it clearer what each contains.
If you or anyone else has a preference as far as which of these approaches (or a completely different approach maybe) you prefer, please let me know.
I am trying to build this on solaris2.6 and am having similar
troubles. I gave up on Install.sh, it's way too unportable
and not really necessary if you install packages regularly.
I had problems with
+ To get configure to find gdbm.h I had to
setenv CPPFLAGS "-I/usr/local/gnu/include \
+ --prefix seems to be ignored. Very confusing.
I spent a few minutes with the Good Book
but couldn't figure out what was up with configure.in
+ assumes gnu tar, which should be mentioned somewhere.
I'm not a configure expert but think it would be simple to
check that tar -zxf works and complain if it doesnt.
Alternatively, check for gzip and unpack with
gzip -dc thing.tar.gz | tar xf -
+ why does it run configure again? I just configured.
+ gmake is assumed. solaris make fails.
+ fails to build because of the CPPFLAGS I defined to
get configure working. Fix was to
(hack out the extra -I flags in the Makefile)
things go fine until:
c++ -c -O2 -DHAVE_CONFIG_H -I../packages/mg/lib \
/usr/ccs/bin/as: "/var/tmp/ccDqQ4tW.s", line 16708: error: can't compute value of an expression involving an external symbol
gmake: *** [display.o] Error 1
gmake: Leaving directory `/scratch/gsdl/lib'
gmake: *** [all] Error 1
I don't understand this. Does it mean I'm forced to use GNU as?
Greenstone has been tested and built on Solaris 2.6.
1) because gdbm does not come standard on solaris, it will be installed somewhere such as /usr/local.
(For us, it is in /opt). We can't really do much about this.
2) --prefix is currently ignored. I personally think this is bad, and will go through and fix
this at some stage in the future.
3) Yes, these options assume gnu's tar. The packages configure/make is a fairly new addition,
so hasn't been as tested. I'll make this change now.
4) the Makefile runs configure if configure.in is newer. It might also run configure in some of the
3rd-party packages directories.
5) Where exactly does solaris make fail?
6) I don't think we've tried compiling under solaris since we added wv. Thanks for that.
7) The assembly error looks a bit bizarre. I just tried it, and it compiled for me:
lucy:~/junk/gsdl/lib$ as -V
as: WorkShop Compilers 4.X dev 18 Sep 1996
However, our c++ is gcc 2.8.1. Maybe that's it.
Sorry I can't help any more than that. Maybe
Stefan can when he gets back.
Thanks for the info,
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.