#14 Cannot run configure script under DJGPP

open
nobody
None
5
2003-05-27
2003-05-27
Jaroslav Fojtik
No

The configure script produces absolutelly strange error:

configure: loading site script g:/gcc/share/config.site
checking for gcc... gcc
checking for C compiler default output... a.exe
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for executable suffix... .exe
checking for object suffix... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking build system type... i386-pc-msdosdjgpp
checking host system type... i386-pc-msdosdjgpp
checking for gettext in -lc... yes
checking for Turbo Vision header files...
e:/src/rhide-1.5/../tvision/include
checking for Turbo Vision libraray...
e:/src/rhide-1.5/../tvision/include/../DJGPP
checking for SET's editor sources...
e:/src/rhide-1.5/../setedit
checking for SET's editor libraries...
e:/src/rhide-1.5/../setedit/makes
checking for bindtextdomain in -lc... no
checking needed libs for gettext... intl
checking for GDB sources... no
configure: WARNING: Could not find GDB sources.
trying older version
checking for GDB sources... e:/src/rhide-1.5/../gdb-5.0
checking GDB objects... e:/src/rhide-1.5/../gdb-5.0
checking for BZ2_bzlibVersion in -lbz2... yes
checking for zlibVersion in -lz... yes
checking for pcre_version in -lpcre... no
checking how to run the C preprocessor... gcc -E
checking for X11/keysym.h... no
configure: creating ./config.status
config.status: creating config.env
configure: configuring in libtvuti
configure: running /bin/sh './configure' --srcdir=.
--cache-file=/dev/null
configure: loading site script g:/gcc/share/config.site
checking for gcc... gcc
checking for C compiler default output... a.exe
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for executable suffix... .exe
checking for object suffix... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking build system type... i386-pc-msdosdjgpp
checking host system type... i386-pc-msdosdjgpp
checking for g++... no
checking for c++... no
checking for gpp... gpp
checking whether we are using the GNU C++ compiler... yes
checking whether gpp accepts -g... yes
checking how to run the C++ preprocessor... gpp -E
checking for streambuf... no
configure: creating ./config.status
config.status: creating config.h
config.status: config.h is unchanged
Configuring /dev/e/src/rhide-1.5 . . .
g:/gcc/bin/cp: `e:/src/rhide-1.5/Makefile' and
`/dev/e/src/rhide-1.5/Makefile' are the same file
g:/gcc/bin/cp: `e:/src/rhide-1.5/rhide.env' and
`/dev/e/src/rhide-1.5/rhide.env' are the same file
make.exe: *** [config] Error 1

Discussion

  • Logged In: YES
    user_id=3906

    This is most probably a problem with your djgpp setup.
    Did you try regenerating the configure script using autoconf?
    This is needed in many cases, thats one of the reasons
    because I think autoconf is useless and I dont use it for
    SETEdit nor TV.

     
  • Logged In: YES
    user_id=106153

    No, I did not try autoconf. In many cases the autoconf
    behaves worse than configure script. A made battle with .ac4
    files etc. I'll try it.
    I attempted to compile Rhide from its own makefiles.
    Compilation hanged after 10minutes.

    Anyway - the rhide is extremly hard to compile. Some
    releases I was absolutelly unable to compile. I invite at
    least something that will ease compilation (cookbook).

     
  • Logged In: YES
    user_id=3906

    I agree compiling RHIDE is complex.
    Mostly because:
    1) It involves compiling gdb, it isnt easy and in fact is
    really hard for djgpp.
    2) Autoconf is really complex, a configure script generated
    in one system doesnt necesary work in another.
    It took me a day to get RHIDE compiled for djgpp. The errors
    where mostly in my djgpp setup which wasnt properly
    configured to support the exigencies of the configuration
    scripts.
    The "for_tvision_2" branch solves a lot of compilation
    issues but doesnt help with the autotools nightmare.