On Friday 26 June 2009 16:52:05 Graham Keeling wrote: > On Fri, Jun 26, 2009 at 11:42:03PM +1000, James Harper wrote: > > I assume the 64 bit build will need the same sort of massaging... > > I'm currently trying to do a 64 bit build from bacula-3.0.1 by trying to > follow the instructions in src/win32/README.mingw. > > I'm coming across all sorts of problems. Has anybody else managed to follow > these instructions and build something? > > > > I have got the cross-tools and depkgs-mingw32 all built and working for > win32. > > README.mingw says this: > > Build the 64 bit cross-tools and mingw64: > > When building the mingw64 environment and all dependencies > > (cross-tools, and depkgs-mingw64) should be compiled by hand with > > host=x86_64-pc-linux and target=x86_64-pc-mingw32. > > ... > > > (It can work with other setup). We are using binutils-2.19, gcc-4.3.2, > > gmp-4.2.4, mpfr-2.3.2. The mingw64 project delivers binaries that should > > do the work. > > README.mingw does not say what mingw-w64 package was used.
I believe we put all the Open Source we used on the Bacula site in something like downloads (or depkgs-mingw32) -- see where the Win32 gets the packages. They should all be there. If not, please let me know again, and I will look at it. If I am not mistaken, with the exception of the gcc version, we used all the same packages we are using for Win32, but a whole lot fewer packages (openssl, pthreads, pcre and zlib) because in Win64 we build only the FD -- haven't even tried for the DIR and SD. > > Eventually, I downloaded mingw-w64-src-4.4.0-1.tar.bz2. It comes with > gcc-4.4.1 and a recent version of binutils. Perhaps I should be using the > exact versions of binutils, gcc, gmp and mpfr as above? But what is the > exact version of mingw64 that I should be using? > > Anyway, I installed all the bits and pieces into the cross-tools directory > as described in README.mingw and hoped that I was going to get somewhere. > > I have made the mingw32-xxx links in $ROOT/cross-tools/mingw-w64/bin. > > I copied build-depkgs-mingw32 to make an equivalent script called > build-depkgs-mingw64. I fixed the paths and changed the places that do > patches to get the xxx-w64.patch files instead, if the xxx-w64.patch files > exist. I uncommented and edited the lines in External-mingw-w64 to get the > right files. > > > zlib, pcre, and pthreads all seem to build and install fine. > The first problem with depkg-mingw64 is that openssl does not work. It > complains about not being able to find zlib.h when trying to compile > c_zlib.c. I didn't have this problem. Perhaps it is a version conflict. Hopefully seeing what we have uploaded will help. > > openssl-w64.patch seems to contain a lot of irrelevant lines. For example, > it creates Configure.orig and sha512.c.orig from scratch, both of which are > (I assume) not used in the build. > I have been giving --with-zlib-include to the Configure script, and I have > checked that I have a zlib.h in the right directory > (depkgs-mingw-w64/include). Yes, a lot of the libraries create a lot of stuff and lots is irrelevant. If I remember the gcc build complains a bit about the docs, but it all seems to run to the end and we don't care about the docs. > > I eventually realised that openssl.patch (rather than openssl-w64.patch) > contains patches that add the --with-zlib-include functionality. So I > thought that perhaps I needed to use both patch files. This is not the > case, as some patches fail when I tried that. > So I ended up combining various patches from each patch file to get openssl > to build. > > > And I've gone on a bit further in this sort of vein. > > >From the experience with openssl, it seems as if the wrong patch files > > have > > been committed to src/win32/patches. Does anybody know anything more about > them? Those are the patches I used. > Kern ------------------------------------------------------------------------------ _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
