I thought of also trying with the master glib. On this one it looks that it fails on gtk-doc, even if there is a flag for disabling gtk-doc from running. Can't get passed that. However, I think it is not the master which i should build so I better find a solution to the problem described in my previous email.
Mihai On Thu, Oct 13, 2011 at 2:25 AM, Mihai Cozma <[email protected]> wrote: > 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
