No matter what I do I get this: *** Checking out glib *** [4/17] git show-ref --quiet --verify refs/heads/win32-2.28.1 git checkout --track -b win32-2.28.1 origin/win32-2.28.1 fatal: git checkout: updating paths is incompatible with switching branches. Did you intend to checkout 'origin/win32-2.28.1' which can not be resolved as commit? *** Error during phase checkout of glib: ########## Error running git checkout --track -b win32-2.28.1 origin/win32-2.28.1 *** [4/17]
[1] Rerun phase checkout [2] Ignore error and continue to configure [3] Give up on module [4] Start shell [5] Reload configuration [6] Go to phase "wipe directory and start over" choice: After googling a bit I have found a command "git remote show origin" and they were all tracked but there was none with that name indeed. Then i changed the jhbuildrc script to include one found there but it didn't work either. No idea what to do next, please help (again :) ) Mihai On Wed, Oct 12, 2011 at 11:25 PM, Mihai Cozma <[email protected]> wrote: > Thanks for the heads up. > > I just got on my machine and I'm making another VM (did't backup the > previous one) for Linux, then I'll try again :). > > Now I understand where I was wrong last night, I tried to built glib > and pixbuf for Linux instead of letting jhbuild building them for > windows. > > So basically I should compile gdk-pixbuf untouched (latest from git) > and patch according to notes only glib, according to your previous > email? > > (About the .dll part, no, it didn't evolved that much, you still have > to restart the application to load it :) > > I'm pretty comfortable with things after they get on Windows, it is > the Linux part only that I'm having trouble with:) I've done Windows > programming for so long now, from as low level as printer drivers to > high level stuff as WPF in .NET, but on Linux I feel like I'm in high > school again, the entire philosophy of how tools work is completely > different :)) > > I'll keep you up to date, thanks > Mihai > > On Wed, Oct 12, 2011 at 10:14 PM, Martin Renold <[email protected]> wrote: >> Okay maybe I explain some of the autoconf and cross-compile basics >> (apologies in case you already got it by now): >> >> When you run ./configure, the script will assume that you want to build for >> the system that you are running on, using the native (runs on linux, builds >> for linux) compiler. The configure script will find linux dependencies >> using pkg-config. And 'make install' will install into your running linux >> system. >> >> Most relevant arguments to ./configure are: >> --prefix (tell it where to install to) >> --host and --target (what system to compile for) >> >> The ./configure script and the compiler will both be looking for libraries >> to link against. On linux, libraries are usually .so files (shared object), >> the equivalent on windows is .dll. So in addition to --target, you need to >> set environment variables such that it does find the cross-compiled >> libraries that you have previously installed into some --prefix=somefolder. >> >> This is done by appending "somefolder" to the search path of various tools >> via environment variables like PKG_CONFIG_PATH, CFLAGS (for the compiler), >> LDFLAGS (for the linker) and more. In addition, you often need to disable >> some features of libraries that only work for Linux. Stuff like >> "--enable-xlib-xrender=no" or "--enable-win32-font=yes". >> >> Just take a look at gtk+-win32.jhbuildrc and you get the idea. This is where >> jhbuild config files are great, they set all this up for you and run >> ./configure within the right environment and the right arguments (usually). >> >> In theory you don't need to install packages like glib2.0-dev if you want to >> build for Windows (mingw32), but sometimes it helps anyway because things >> are not always perfect, and it may install a couple of useful dependencies >> (like pkg-config) that you need anyway. >> >> When you finally have built gtk+ for Windows, "make install" (called by >> jhbuild) will have installed into its --prefix folder (target.dbg). >> You will find the .dlls (and all the .dlls it depends on) in target.dbg/lib/. >> >> Now the last step is to figure out where your MyPaint installation keeps >> those same DLLs, and replace them with the ones that you have built. Not >> sure any more if the lib/ directory is sufficient, if you find a similar >> directory structure it's probably better to copy everything (etc, include, >> lib, bin, share...). Don't delete the old stuff, unless you want to >> re-compile really everything, like Python and PyGTK. Those two will load >> your libgtk.dll, but it is not neccessary to recompile them yourself because >> all GTK2 .dlls should be backward compatible. >> >> About compiling MyPaint: >> >> It may sound funny, but you don't need GTK to compile MyPaint. The >> compilation process will only link against glib and libpng (IIRC). This is >> because the only thing that needs compiling is a Python extension module. >> This module contains only the time-critical code and does not interact with >> the GUI elements directly. Instead, it does render pixels into a memory >> buffer on request, and similar things. >> >> However PyGTK (which is also a compiled Python extension module) is linked >> against GTK, and will cause Python to load the GTK .dll at runtime. >> >> About installing, when a program is running its libraries are generally >> loaded into memory, so when you replace a .dll you will at least need to >> restart the program to load the new library from disk. (Unless library >> technology has advanced a hell lot while I was not looking.) >> >> Hope this helps to clarify things a bit. >> >> -- >> Martin Renold >> > _______________________________________________ Mypaint-discuss mailing list [email protected] https://mail.gna.org/listinfo/mypaint-discuss
