broken after ./configure and make

Tom Porter
  • Tom Porter

    Tom Porter - 2001-03-05

    I downloaded gsdl 2.31 Linux source, as well as all the manuals and while ./configure and 'make' worked fine, 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, did not work.

    The error is: 'could not locate /tmp/Unix/bin/linux'. Even if I could get by this, 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 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 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, 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, 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.

    Tom Porter

    • Anonymous - 2001-03-05

      I think that the problem here is that
      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 ./". 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,
      John McPherson.

    • Tom Porter

      Tom Porter - 2001-03-06

      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 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, which gave me the errors I listed.

      No where in the directory structure I downloaded is there a Unix directory as the 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


      Tom Porter

    • Stefan Boddie

      Stefan Boddie - 2001-03-06

      Hi Tom,

      You're quite right that 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 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 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.

      Stefan Boddie

    • Vince McIntyre

      Vince McIntyre - 2001-03-13

      I am trying to build this on solaris2.6 and am having similar
      troubles. I gave up on, 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

      + 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
           cd gsdl/packages/wv/wv-gs/libole2/
           (hack out the extra -I flags in the Makefile)
           cd ..
           cd ../..
           cd ..

      things go fine until:
      c++ -c -O2 -DHAVE_CONFIG_H -I../packages/mg/lib \    -I.. display.cpp
      /usr/ccs/bin/as: "/var/tmp/ccDqQ4tW.s", line 16708: error: can't compute value of an expression involving an external symbol
      gmake[1]: *** [display.o] Error 1
      gmake[1]: Leaving directory `/scratch/gsdl/lib'
      gmake: *** [all] Error 1

      I don't understand this. Does it mean I'm forced to use GNU as?

      • Anonymous - 2001-03-13

        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 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,
        John McPherson.


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks