This is the mail archive of the 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]
Other format: [Raw text]

results of compiling berkeleydb

Ok, I did as requested, and tried to compile berkeleydb with -mno-cygwin. Results are
below, along with some thoughts/reflections....


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"


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"


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/ *-*-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

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:


into C:\mingw, and:

vim Makefile

edit, add: 

CPPFLAGS= -I/cygdrive/c/mingw/include ..
LDFLAGS = -L/cygdrive/c/mingw/lib ..

make clean


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@localhost(...db-4.1.25/dist) % setenv MINGW 1
esp@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@localhost(...db-4.1.25/dist) % make
esp@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'.


	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.


Unsubscribe info:
Problem reports:

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