From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Charles S. Wilson" To: "David A. Cobb" Cc: Cygwin General MailList Subject: Re: Making GDBM [ a long story ] Date: Sat, 14 Jul 2001 19:55:00 -0000 Message-id: <3B51061D.8030305@ece.gatech.edu> References: <5.1.0.14.0.20010713193611.037f6060@mail> X-SW-Source: 2001-07/msg00797.html 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/