[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] need error message for missing dlls on Windows
From: |
Stephen Leake |
Subject: |
Re: [Monotone-devel] need error message for missing dlls on Windows |
Date: |
Mon, 21 May 2007 19:31:27 -0400 |
User-agent: |
Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (windows-nt) |
Matthew Gregan <address@hidden> writes:
> At 2007-05-20T10:42:00-0400, Stephen Leake wrote:
>> When I run a mtn on Windows, it fails with no message if the required dlls
>> are not in PATH.
>
> The DLLs do not need to be in the PATH. Windows will look for them in the
> same directory as the monotone executable.
Right.
>> It is not hard to arrange for them to be in PATH; my problem is how to
>> get a good error message from mtn, rather than the current silence.
>>
>> I compile mtn with MinGW, but I typically don't have MinGW in PATH
>> when running, which is why I noticed this problem.
>
> Use the Windows installer from monotone.ca or install your built version in
> a similar way (with the required DLLs in the same directory as mtn.exe) and
> it should be fine.
Well, I'm running it from the build directory, because I'm editing it
often.
I just switched computers, and got the same non-error message again
:). Which is what prompted this post.
>> I assume the linker has added some dll loading code before the call to
>> 'main'.
>
> Not exactly. The runtime linker does this work before any code in the
> monotone executable gets a chance to run.
Ah. So I can blame the lack of a good error message on Microsoft. Not
at _all_ surprising!
> We can look at linking the libraries statically, but I'm not sure it's worth
> the effort--we already distribute monotone in such a way that it'll Just
> Work. It's only because you're building from source and not setting the
> runtime environment up appropriately that you're running into this problem.
Right.
> Using LoadLibrary/GetProcAddress to load the libraries at runtime is not an
> option, it'd be a whole lot of extra maintenance burden for very close to no
> benefit.
Right.
--
-- Stephe