[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Build monotone with Microsoft Visual Studio 2005

From: Timothy Brownawell
Subject: Re: [Monotone-devel] Build monotone with Microsoft Visual Studio 2005
Date: Tue, 19 Sep 2006 08:40:33 -0500

On Tue, 2006-09-19 at 11:21 +0200, Jesper Ribbe wrote:
> Hello,
> I've tried to build monotone with MVS-2005 to track the filesystem 
> conversion problems I've had.
> I followed the instructions on the wiki and have succesfully built boost.
> However I've got some problems when building monotone itself with the 
> supplied visualc/monotone.sln:
> 1.
> There seem to be some files missing in the solution which gave me link 
> errors:
> win32\
> After adding these files to the monotone project, I could successfully 
> build it.

I don't think any of us use VS regularly (I used to check
semi-regularly, but my vmplayer is broken right now :( ). The visualc/*
files were last updated about a month ago, and those files were all
added after that.

> 2.
> The sub-project "tester" didn't build. It gave quite a few errors, and 
> I've not tried to correct them. Instead I skipped the project as I 
> wanted a working mtn.exe first.

Huh. I hadn't thought we'd changed what files that used in the last

> 3.
> The zlib1.dll and libiconv2.dll mentioned in the wiki are linked to 
> MSVCRT.DLL which indicate that they are built with Visual C++ 6.0. using 
> dlls built with VC6 within MVS-2005 is a well known problem in the 
> windows world. This is probably the cause of the memory access violation 
> inside strlen() which is what I get when running the produced mtn.exe.

So we'd have to... find a version that's compiled with VS2005 (is there
one?)? Provide a VS2005 compiled version ourselves (what happens if the
user also wants to use it with something compiled with VC6?)? Provide
instruction for building it and putting the resulting dlls in the same
place as mtn.exe?

> These problems make me believe that MVS-2005 is not the recommended 
> build environment on Windows.

Yeah, it's not really.

> Would it be interesting if I tried to solve these problems and produce a 
> patch? Or is mingw the only realistic option?

Interesting, yes. Useful... only somewhat, at least until someone (you,
perhaps? ;-) starts building semi-regularly under VS to make sure the
build files *stay* up-to-date.

Free (experimental) public monotone hosting:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]