[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] mingw-instructions
From: |
Stephen Leake |
Subject: |
Re: [Monotone-devel] mingw-instructions |
Date: |
Mon, 10 Jan 2011 05:02:13 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.2 (windows-nt) |
Timothy Brownawell <address@hidden> writes:
> 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...
Good point.
> which seems to already be the case, see {unix,win32}/parse_date.cc .
That was me. We should have a project-wide agreement on using GPL 3 for
new code (or not).
>>> 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.
Excellent.
However, it would be best to put those flags in Makefile.am, in the 'if
WIN32_PLATFORM' conditional.
Hmm. I just tried that, and got "g++.exe: unrecognized option
`-static-libstdc++'"; I have g++ 3.4.5 installed in MinGW. So if we put
it in Makefile.am, it needs to be conditional on the g++ version that
configure finds.
Will Debian have the same problem when it upgrades to a newer g++?
I guess not; Squeeze is at g++ 4.4.5, and it shows mtn dynamically
linked with libstdc++.so.6 and libgcc_s.so.1.
I wonder why those particular dynamic links are slow on MinGW?
--
-- Stephe
- [Monotone-devel] mingw-instructions, Stephen Leake, 2011/01/08
- Re: [Monotone-devel] mingw-instructions, Thomas Keller, 2011/01/08
- Re: [Monotone-devel] mingw-instructions, Stephen Leake, 2011/01/08
- Re: [Monotone-devel] mingw-instructions, Timothy Brownawell, 2011/01/08
- Re: [Monotone-devel] mingw-instructions, Stephen Leake, 2011/01/09
- Re: [Monotone-devel] mingw-instructions, Hendrik Boom, 2011/01/09
- Re: [Monotone-devel] mingw-instructions, Stephen Leake, 2011/01/09
- Re: [Monotone-devel] mingw-instructions, Hendrik Boom, 2011/01/09
- Re: [Monotone-devel] mingw-instructions, Timothy Brownawell, 2011/01/09
- Re: [Monotone-devel] mingw-instructions,
Stephen Leake <=
- Re: [Monotone-devel] mingw-instructions, Hendrik Boom, 2011/01/10
- Re: [Monotone-devel] mingw-instructions, Richard Levitte, 2011/01/09
- Re: [Monotone-devel] mingw-instructions, Thomas Keller, 2011/01/09