Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com X-Authentication-Warning: mdssirds.comp.pge.com: esp5 set sender to esp5 AT pge DOT com using -f Date: Sun, 12 Oct 2003 18:03:44 -0700 From: Edward Peschko To: cygwin AT cygwin DOT com Subject: results of compiling berkeleydb Message-ID: <20031013010344.GA18830@mdssirds.comp.pge.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Ok, I did as requested, and tried to compile berkeleydb with -mno-cygwin. Results are below, along with some thoughts/reflections.... Ed ---- general nitpicks: ---- 'which' returns /cygdrive/c form instead of C:\... no way of switching doesn't play well with applications outside of cygwin (for example: touch >> /tmp/2 gvim (native windows executable) /tmp/2 returns 'file not found'. need to prefix it with gvim 'C:/cygwin/tmp/2' assuming installed in C:\cygwin. (both sh and tcsh have this problem.) directory softlinks as .lnk files, not as junctions. Can't 'cd' into a link, various windows programs have problems with reading the softlink. Make 'softlink == hardlink' on NT/2000/xp systems? (softlinks as '.lnk', yes I know there is an option to disable this, but this should be IMO default as windows xp/2000/nt have *good* links.) form of 'grep dropped -r .' does not work, need to use form 'grep -r mingw .' clipboard seems to be malfunctioning, text cannot be copied to it. ---- compiling berkeleydb: ---- trying to port berkeleydb as mingw ./configure --prefix=/install/berkeleydb --build=i686-pc-mingw32 compiles fine, does not invoke -mno-cygwin. objdump -p ./db_recover.exe | grep "DLL Name" gives DLL Name: cygwin1.dll DLL Name: KERNEL32.dll .... make realclean rm config.cache ./configure --prefix=/install/berkeleydb --build=i686-pc-mingw32 --target=i686-pc-mingw32 objdump -p ./db_recover.exe | grep "DLL Name" gives DLL Name: cygwin1.dll DLL Name: KERNEL32.dll .... Ok, so berkeleydb's configure process knows nothing about -mno-cygwin, grep no-cygwin -r . -r: No such file or directory oops, make that: grep -r no-cygwin . ./aclocal/libtool.ac: *-*-cygwin*/gcc*-mno-cygwin*|*-*-mingw*) hmm. libtool has something, at least the .ac file (which I'm assuming is the template and is not the one being used in the compilation) So, I'll add it manually to the Makefile: edit Makefile inside dist => add LDFLAGS == -mno-cygwin hmm. Errors: db_archive.o(.text+0x2c1): db_archive.c: undefined reference to '____errno') db_archive.o(.text+02d2):db_archive.c: undefined reference to '____getreent' ... ... hmm. missing symbols. Looks like the mingw32 runtime libraries are missing, so I search the net and see 'http://www.delorie.com/howto/cygwin/mno-cygwin-howto.html' and find: >> ... undefined reference to ___errno' >> Ouch! what went wrong here? Its such a trivial piece of code.. The problem here is that >> the Cygwin development tools provide *only* the Mingw32 C runtime libraries...." ..and goes on to mention the prickly nature of mingw and cygwin having either the same file _G_config.h with differences or when Cygwin has a file that mingw32 doesn't. As of now, it looks like even these have been removed because berkeley db is a c program, but for now I go to the net and install: MinGW-3.1.0-1.exe into C:\mingw, and: vim Makefile edit, add: CPPFLAGS= -I/cygdrive/c/mingw/include .. LDFLAGS = -L/cygdrive/c/mingw/lib .. make clean make: argh. more errors: db.h:90: error: parse error before "db_pgno_t" db.h:90: warning: data definition has no type or storage class. ==== At this point, I probably would throw up my hands, and head for mingw instead and indeed have two separate development environments. Since this is just a C program, the problems that I would get from a C++ program or a fortran one would probably be more severe. ---- benefits of integrated mingw and cygwin ---- Now, if mingw and cygwin were *truly* integrated, I would only have to say: esp AT localhost(...db-4.1.25/dist) % setenv MINGW 1 esp AT localhost(...db-4.1.25/dist) % ./configure --prefix=/install/berkeleydb .... checking build system type... i686-pc-mingw32 checking host system type... i686-pc-mingw32 .... esp AT localhost(...db-4.1.25/dist) % make esp AT localhost(...db-4.1.25/dist) % make install The people who make berkeleydb configure would not need to know that you are cross-compiling and they need not know -mno-cygwin because it would be implicit in everything that gcc, ld, etc. does. config.guess would return 'pc-mingw32' in MINGW mode. Furthermore, as part of what the MINGW switch does, it would disable all headers and libraries in the cygwin tree so such errors as 'picking up the wrong _G_config.h' and 'in no-cygwin mode: picking up a file that exists in cygwin' would go away. This would allow for better error handling - as the errors would always be pointing to the 'right place'. And: a) you could make the MINGW version of the utilities act in a more win32 way, getting rid of a lot of annoyances as listed above. b) you'd get a lot of testing and bugfixing of the merged software from existing mingw users. c) people would be able to use all the unix tools (screen, vim, emacs, grep, etc) to develop these native Win32 apps in a coherent package. d) the inefficiencies in supporting two separate projects which basically are doing the same thing in two separate ways would go away. causing, as I said, a *lot* less confusion. Ed -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/