On 5/25/2010 5:16 AM, i-love-spam wrote:
>> Broken? Larger size on disk is "broken"? I don't think that word
>> means what you think it means.
> The moment I wrote about that I didn't know what was the issue and I
> wouldn't care much considering what env should do: list environment
> variables. 1MB is just TOO much for it. Not that I don't have space
> on my pc... I wanted to make standalone bundle of msys with my
> crosscompiler and updated coreutils made it twice larger :) So, I
> made a simplest conclusion : broken! :)
In other words, you think that one of the definitions of "broken" is
"bigger than I like". As I said, I don't think that word means what you
think it means.
> Most likely even in some distant parts of china they don't care much
> if env, set, echo etc contain anything in chinese. Why not provide
> binaries without that 18in junk? :)
Because I have no intention of providing two separate versions. And,
disk space is cheap, there was no download impact thanks to lzma, AND I
knew the problem would eventually be resolved once we could build
libintl as a DLL. So: virtually no cost (and now, zero cost), to be a
good member of the (majority non-English-speaking) world.
> I'm not sure if it's acceptable tradoff or not
We are. And now, it's not a tradeoff at all -- because NOW, we actually
have a DLL version of libintl.
> I'm still in search
> to find reasonable explanation why ./configure on cygwin/msys of some
> apps that I need to build/update quite frequently takes like 10 times
> more time than a less powerfull linux with mingw crosscompiler...
The win32 subsystem in Windows is NOT posix, and its model for spawning
new processes differs substantially from that of posix. To emulate the
posix model (which is what cygwin and msys do) requires a LOT of
book-keeping effort. All that effort slows down process creation a LOT.
> Considering that configure runs many binaries in chain for simplest
And this is why configure scripts are particular susceptible to the
slowdown in process creation. It's just part of the cost of emulating
POSIX on top of windows.
When running a cross compiler on linux -- you're on a posix system.
Process creation just works The Posix Way, with no "extra" bookkeeping
to emulate. I've even seen it mentioned that running a cross compiler
within a linux session in a virtual machine hosted on win32 is actually
faster than using cygwin or msys -- so you might want to investigate
that avenue if cygwin/msys are too slow for your tastes.
(Modern hardware support for virtualization means that there is only a
5-10% virtualization penalty. So, it's fairly easy to see that
5%-slower-than-'real'-linux is probably faster than
massive-posix-emulation-slowdown on the same hardware.)
> I guess that 1MB binaries are a bit to heavy.
No, given modern drive speeds, data caching, and read lookahead, loading
1MB binaries is not substantially slower than loading 20k ones. The
overhead, as I said above, is in emulating the posix fork/exec model
using the very different CreateProcess() win32 api.
> Yes, I wasn't using dvlpr shell. ... For dvlpr I don't need to have a separate
> installation of msys, right?