My understanding is that cygwin is *only* used for making the dll. For this purpose asdf excutes these cygwin commands:
gcc -mno-cygwin -mwindows -c -Wall -std=c99 -L/c/Programme/Oracle/Berkeley\ DB\ 4.5.20/lib/ -I/c/Programme/Oracle/Berkeley\ DB\ 4.5.20/include/ libberkeley-db.c dlltool -z libberkeley-db.def --export-all-symbols -e exports.o -l libberkeley-db.lib libberkeley-db.o gcc -shared -mno-cygwin -mwindows -L/c/Programme/Oracle/Berkeley\ DB\ 4.5.20/bin/ -llibdb45 libberkeley-db.o exports.o -o libberkeley-db.dll With these settings in config.sexp #+(or mswindows windows) ((:berkeley-db-include-dir . "C:/Programme/Oracle/Berkeley DB 4.5.20/include/") (:berkeley-db-lib-dir . "C:/Programme/Oracle/Berkeley DB 4.5.20/bin/") (:berkeley-db-lib . "C:/Programme/Oracle/Berkeley DB 4.5.20/bin/libdb45.dll") (:berkeley-db-deadlock . "C:/Programme/Oracle/Berkeley DB 4.5.20/bin/db_deadlock.exe") (:pthread-lib . nil) (:clsql-lib . nil) (:compiler . :cygwin)) the bdb dll installed from the .msi file is used, which is libdb45.dll. The install instructions could look like this: 1. install bdb for windows (.msi) 2. modify adapt the bdb directories in config.sexp 3. install cygwin including mingw 4. mount C: as /c/ 5. comment these lines out in C:\cygwin\usr\include\mingw\sys\types.h: /* *#ifndef _SSIZE_T_ *#define _SSIZE_T_ *typedef long _ssize_t; * *#ifndef _NO_OLDNAMES *typedef _ssize_t ssize_t; *#endif *#endif * Not _SSIZE_T_ * */ 6. load ele-bdb with asdf Ian: the bdb directories seem to be hardcoded then. I mean if I transfer an executable to another computer where bdb is installed at a different place, it will not work? Frank > -----Ursprüngliche Nachricht----- > Von: Elephant bugs and development <elephant-devel@common-lisp.net> > Gesendet: 23.03.07 15:23:10 > An: Elephant bugs and development <elephant-devel@common-lisp.net> > Betreff: Re: [elephant-devel] Start of 0.6.1 Beta Cycle > On Fri, 23 Mar 2007 10:11:58 -0400, Ian Eslick <[EMAIL PROTECTED]> wrote: > > > I think the cygwin version is slow to update their versions and for > > various reasons we tend to depend on the latest release (4.5 in this > > case). > > Really? I thought that BerkeleyDB was always distributed as a whole > with all versions in one package. The "build_unix" directory was in > the directory installed by the binary Windows (.msi) distribution and > I could build a Cygwin DLL from there without problems. > > But, as I said, I'd prefer a "native" DLL over a Cygwin one. (I > understand that you're building your own libs with "--no-cygwin" and > "--mingw32" but that wouldn't be the case for the BerkeleyDB DLL > then.) > > > Your point on windows builds is well taken. Here is a possible > > approach: > > > > By default, we distribute DLLs with major releases and major > > development checkpoints. There is a configuration option to inhibit > > compilation. If people want to track the development tree, they'll > > have to enable this switch and then dig into why it doesn't work. > > The current DLLs shouldn't depend on cygwin (--no-cygwin --mingw32). > > However they'll only work on 32-bit Windows. > > Sounds very good to me! > > > Does cygwin do cross-compilation for 64-bit windows? > > Ugh, I don't know... > _______________________________________________ > elephant-devel site list > elephant-devel@common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel > _______________________________________________________________ SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192 _______________________________________________ elephant-devel site list elephant-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/elephant-devel
