monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] mingw-instructions


From: Timothy Brownawell
Subject: Re: [Monotone-devel] mingw-instructions
Date: Sun, 09 Jan 2011 21:07:27 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101213 Iceowl/1.0b2 Icedove/3.1.7

On 01/09/2011 04:16 AM, Stephen Leake wrote:
> Timothy Brownawell <address@hidden> writes:

>>> (which we should upgrade to).
>>
>> Eww.
> 
> Can you elaborate? GPL 3 is technically more sophisticated than GPL 2. 

Mostly I'm annoyed at the change from straight copyleft to forbidding it
from being used as part of things with certain properties. Not that the
particular properties they picked are likely to be relevant for a
developer tool, so maybe it doesn't really matter that much...

> I don't think the process of upgrading requires getting approval from
> all current authors, because our license statements say "GPL 2 or greater".
> But I'm not a lawyer, so maybe that doesn't mean we get to change it to
> "GPL 3 or greater".

AIUI changing the license statements on existing code requires
agreement, but you could also get much the same effect by just changing
the statements for new code... which seems to already be the case, see
{unix,win32}/parse_date.cc .

>>>> so a general disclaimer like the one you stated above might be the way
>>>> to go (or even something more general like "we tested this with
>>>> release so-and-so last time, everything might have changed in the
>>>> meantime").
>>>
>>> Ok, I've left that milestone in 1.0 in RoadMap.
>>
>> Speaking of which, does anyone know why a monotone built with the new
>> instructions might eat several seconds of CPU time before entering
>> main(), 
> 
> ouch!
> 
> It's probably some library initialization; maybe reading all the
> internationalization files? But that should be the same on Linux.
> 
> Maybe some library is interacting with the Windows Registry?

Running "time mtn.exe" showed several seconds wall time but no CPU time.
So I tried searching for any known issues with the newer mingw g++ that
might slow down the dynamic linker (as something that runs before the
new process is really itself), and then thought to check it with
depends.exe.

It was dynamic-linking libgcc_s and libstdc++-6 (and a mtn built with
the old instructions wasn't). Building with
"-static-libgcc -static-libstdc++" in LDFLAGS and CXXFLAGS fixes it.
I'll document that in INSTALL_windows_native.txt, and then
nvm.mingw-instructions should be mergeable.


-- 
Timothy

Free public monotone hosting: http://mtn-host.prjek.net



reply via email to

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