Hi, On Wed, 23 Jan 2008, Christian Stimming wrote:
> Attached you find my current progress - a patch against your temp/msys > branch of msysgit.git. Thanks. Very much appreciated. > As it turned out, python indeed is not necessary, but one has to comment > out the respective commands in autogen.sh or else important parts of > autogen do not get executed. Good. > Also, I think the additional libtool installation is necessary. I don't > understand what you mean by msys/mingw modes of libtool Sorry, I did not mean to be cryptic, but I was. 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. For example, MinGW32 programs cannot use fork(), because fork() is POSIX and not contained in the Windows API. 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. It is pretty easy to tell if a program is MSys or MinGW32: the latter will reside in /mingw/bin/, the former in /bin/. (Yes, git.exe is in the wrong folder, technically, but there are a few scripts too, and those _need_ MSys, so git is kind of a chameleon.) 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). The way you compile an MSys program is to set the environment variable "MSYSTEM" to "MSYS". Voila. Of course, the MinGW32 people would rather have you compile MinGW32 programs, so they make it extra hard to compile MSys programs. As you saw, libtool is incomplete for MSys (but it could be my fscking up the msysDVLPR installation, too). One of the differences when MSYSTEM=MSYS (as compared to MSYSTEM=MINGW32) is that "uname" reports "msys". And since one of your patches switches "cygwin*" to "mingw32*", I assume that your MSYSTEM is _not_ MSYS. Now, I could be totally wrong in expecting that you _need_ to compile subversion as an MSys program (or at least the perl bindings), but I think that most likely, a MinGW32 subversion perl binding will not work. > - what *I* mean is that in the temp/msys branch, the installation of > libtool seems to be incomplete so that you cannot run "libtoolize", > which autogen.sh tries to do and fails. (Try it: run "libtoolize" in the > subversion-1.4.6 directory.) The error message points to some missing > directories. Newly installing libtool fixes this. 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. So it seems that I wasted a lot of time, running around in circles, only because I borked the _first_ step. Sigh. 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, but all of a sudden, apr's configure just dies when determining anonymous memory or some such. Should I move the branch to msysgit.git? Comments? > My machine hasn't finished the build from a pristine tree yet > (everything so darn slow on windows), but with my yesterday's build I > was indeed able to create and install the full swig-pl modules. git-svn > could be started - except that I got some weird DLL mixup error. Will > continue to investigate. Note: this could be the problem I referred to as MSys/MinGW32 mixup. > Also, suddenly I get an error during building of neon/src/ saying > "libtool: syntax error near unexpected token |" which is due to an empty > variable global_symbol_pipe in the neon/libtool program. No idea where > this suddenly comes from; it didn't occur in my previous builds. Will > continue to investigate. I guess this could stem from you restarting msys.bat (in which case, MSYSTEM is forced to MSYS). Thanks, Dscho
