Am Mittwoch, 23. Januar 2008 13:08 schrieb Johannes Schindelin: > MSys and MinGW32 are two different things. MinGW32 is really a minimal > toolset to produce native Windows programs -- such as git. MSys is just a > cut-down fork of cygwin to help make MinGW32. (...) > > Of course, programs like bash or perl _need_ fork(). (Actually, they need > something like spawnvpe() but because Microdaft borked up their _own_ > implementation of it, it's next to unusable.) > > That's the reason why bash or perl are compiled as _MSys_ programs. They > link with msys-1.0.dll, which provides a rudimentary POSIX layer, _just_ > enough to get bash and perl going.
Thanks for the explanation. In fact I had been working only with mingw programs - they only linked to the (very small) mingwm32.dll. Now that you mention it, I can see clearly how perl.exe et al also link against msys-1.0.dll. In gnucash, we got away without msys-1.0.dll by using the glib-implemented variety of fork(), but I also didn't know about the msys layer. > The thing is, since Perl is an MSys program, I am pretty confident that > subversion (at least its perl bindings) also need to be compiled in MSys > mode (automatically linking to msys-1.0.dll). Well, I'm not yet completely convinced this to be inevitable, but it might be highly probable. > And since one of your patches switches "cygwin*" to "mingw32*", I assume > that your MSYSTEM is _not_ MSYS. The MSYSTEM variable is MSYS here, because I restarted msys.bat just as you said :-) I used mingw32 there because that's what I always > Okay, I just checked, and it seems that I actually borked the install of > msysDTK (not DVLPR). And it seems that libtool and autoconf/automake > _are_ included, _and_ work very well for MSys. Err... you mean msysDTK-1.0.1.exe was messed up? I see that msysgit.git contains much newer autoconf etc tools, which is probably better. > I am not sure if I want the complete msysDVLPR and msysDTK in > msysgit.git... so I pushed it to historical-msysgit.git, as > "msysDVLPRandDTK". libtool now works, I'm fine with whereever you push them to. Just tell me how to obtain the same build environment as you have again. For me, one particular branch in msysgit.git would be easiest. > but all of a sudden, apr's > configure just dies when determining anonymous memory or some such. I think I've seen this error as well but it disappeared again. I think it went away either after I updated libtool or I specified the --build argument at configure. I'll continue to check how to build this. If you have any updates to the temp/msys branch I'd happily pull those. Christian Christian
