This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Making GDBM [ a long story ]


Note that normally, you don't have to specify "--with-this" or 
"--without-that".  If you have "this" installed, configure will 
automatically build with "this".  If you don't have "that" installed, 
configure will detect the absence and build without "that".

So, since you have postgres installed, Xemacs finds and uses it. 
Mystery #2 solved.  Now, about mystery #1...


> checking for pgsql/libpq-fe.h... no
> checking for postgresql/libpq-fe.h... yes
> checking for PQconnectdb in -lpq... yes
>     Defining HAVE_POSTGRESQL
> checking for PQconnectStart in -lpq... yes
> ! *** Even though I didn't request --with-database=postgresql !


[snip]

> checking for esd-config... no
>     xemacs will be linked with "miscplay.o"
> ! *** THIS IS GOING TO BE ANOTHER PROBLEM *** !


Looks like a mistake in the XEmacs 21.5 series.  Many times the linux 
folks put in a change that causes regression failures like this -- 
especially on cygwin.

> . . . .
> AND FINALLY
> . . . .
> checking for database support
> checking for ndbm.h... no
> Error: Required DBM support cannot be provided.
> :[S!] Bash $


Well, since
   (a)/usr/include/ndbm.h DOES exist (if you've installed the gdbm 
package) and
   (b) I and many others HAVE successfully built XEmacs with gdbm 
support on cygwin in the past (21.4.3 and prior)

This again looks like some sort of regression failure in XEmacs' 
configure script.


> Aha! Maybe I need to build it locally {I thought}, so - get the source 
> and . . . .


This should never be necessary.  If a package has been ported and 
included in the official dist, then it should work.  If it doesn't, then 
it's a bug -- either in the "official" package or the client code you're 
trying to build.  You shouldn't need to go rebuilding stuff on your own 
-- unless you're a glutton for punishment.


> :[S!] Bash $ ../configure --target=i686-pc-cygwin \
>  > --without-x \
>  > --with-gnu-ld \
>  > --exec-prefix=/usr/local/i686-pc-cygwin/
[snip]
> creating Makefile
> creating autoconf.h
> :[S!] Bash $ make
> /bin/sh ../libtool --mode=compile /usr/bin/gcc -mcygwin -c   -I. -I.. -O 
> ../dbminit.c
> ../libtool: Can't open ../libtool: No such file or directory
> make: *** [dbminit.lo] Error 2


Well, it looks like you're building gdbm from the official GNU source. 
AFAIRC, gdbm *does* build OOB on cygwin -- if all you want is the static 
lib.  Why didn't you use the cygwin-patched source from sourceware? 
Also, I *vaugely* remember something about the permissions in the 
official GNU tarball on "litool" not being executable -- if you're using 
CYGWIN=ntsec.  But I could be mistaken.


> SO, obviously I should do something differently.  What?


Well, w.r.t. building gdbm, I'm not sure.  "It works for me"(tm). 
However, with regards to XEmacs, I'd try to track down in the XEmacs 
configure script exactly *WHY* it claims that ndbm.h is missing, and 
take it to the xemacs-nt mailing list.

--Chuck
cygwin-gdbm maintainer



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]