Re: [Monotone-devel] mingw-instructions

[Stephen Leake]

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