From: Ronan W. <wa...@gm...> - 2013-05-16 13:01:12
|
hi, I've been trying to build Gramps trunk for some time now, and running into basic stumbling blocks along the way (the most recent being that the wiki referred to the old SVN repo; I've since corrected this, but there are a few more problems with that particular wiki that I don't want to touch until I have a clean, working build). As of yesterday I managed to get a complete build, but it wouldn't launch as it was missing some of the BerkeleyDB support. So, a question: is anyone aside from John tracking gramps-svn builds on Mac, and if so, what's your build sequence look like? Right now I'm attempting to reconstruct yesterday's successful build, and I have this: jhbuild bootstrap jhbuild build libpng libtiff libxml2 python jhbuild --moduleset=gramps-mac/gramps.modules build gramps-svn This currently bombs on building PIL as the gramps-svn dep appears to be on pil-py3k; I got it working yesterday by rewinding the relevant checkout to the point where pil-py3k forked from pil (so it's python-2 compatible) but obviously that's not right so I'm just now setting up a build using python3. I'm also aware there are various meta-packages which may resolve some of these dependencies, but as noted the wiki docs don't quite match the available deps so I'm trying to construct a minimal set of what works, rather than hunting down build failures in things that I don't need. (naviely, it seems that I should only need to build gramps-svn, and it should magically pull in all the deps it needs) Guidance appreciated. Once I've got something that builds and runs I'm quite happy to set up a tinderbox-ish environment that repeatedly builds into a clean environment, but I need to get to that clean build first. Oh, and obviously if there's an updated Wiki on all this that I've overlooked, just point me at that and I'll hang my head in shame :) cheers, Waider. -- wa...@gm... / It's about as impersonal as you can get. |
From: John R. <jr...@ce...> - 2013-05-16 14:12:24
|
On May 16, 2013, at 6:01 AM, Ronan Waide <wa...@gm...> wrote: > hi, > > I've been trying to build Gramps trunk for some time now, and running > into basic stumbling blocks along the way (the most recent being that > the wiki referred to the old SVN repo; I've since corrected this, but > there are a few more problems with that particular wiki that I don't > want to touch until I have a clean, working build). As of yesterday I > managed to get a complete build, but it wouldn't launch as it was > missing some of the BerkeleyDB support. So, a question: is anyone aside > from John tracking gramps-svn builds on Mac, and if so, what's your > build sequence look like? > > Right now I'm attempting to reconstruct yesterday's successful build, > and I have this: > > jhbuild bootstrap > jhbuild build libpng libtiff libxml2 python > jhbuild --moduleset=gramps-mac/gramps.modules build gramps-svn That won't work. It won't even come close. The list of modules in the wiki is a bit out of date for gramps-svn (I'll fix it right after sending this): jhbuild --moduleset=~/gramps-mac/gramps.modules build meta-gtk-osx-bootstrap meta-gtk-osx-gtk3 berkeleydb4.8 python2.7 meta-gtk-osx-python-gtk3 gramps-svn It should be jhbuild --moduleset=~/gramps-mac/gramps.modules build meta-gtk-osx-bootstrap meta-gtk-osx-gtk3 meta-gtk-osx-freetype berkeleydb python meta-gtk-osx-python-gtk3 gramps-svn Notice that both berkelydb and python are in the list. That's because the Apple-provided python doesn't include bdb support. Notice also the meta packages, which group together blocks of dependencies. Your small list of modules misses most of those. You had trouble earlier with graphviz's dependency on pango-ft: Building meta-gtk-osx-freetype resolves that dependency. > > This currently bombs on building PIL as the gramps-svn dep appears to be > on pil-py3k; I got it working yesterday by rewinding the relevant > checkout to the point where pil-py3k forked from pil (so it's python-2 > compatible) but obviously that's not right so I'm just now setting up a > build using python3. I'm also aware there are various meta-packages > which may resolve some of these dependencies, but as noted the wiki docs > don't quite match the available deps so I'm trying to construct a > minimal set of what works, rather than hunting down build failures in > things that I don't need. Don't do that. You do need everything in the meta packages. As for PIL, the tarball in gramps.modules (Imaging-1.1.7.tar.gz) is correct for Python 2.7.2; since Python3 presents problems building GObject-introspection I'm not using it and the pil-py3k is commented out. > > (naviely, it seems that I should only need to build gramps-svn, and it > should magically pull in all the deps it needs) That would be ideal, but there are some soft dependencies in the gtk-osx modulesets that prevent it. > > Guidance appreciated. Once I've got something that builds and runs I'm > quite happy to set up a tinderbox-ish environment that repeatedly builds > into a clean environment, but I need to get to that clean build first. > > Oh, and obviously if there's an updated Wiki on all this that I've > overlooked, just point me at that and I'll hang my head in shame :) > The wiki has fallen behind changes in the structure of the modulesets, sorry. I'll get that fixed up today. Regards, John Ralls |
From: Ronan W. <wa...@gm...> - 2013-05-16 14:15:42
|
Thanks for that, John. I'll give it a whirl and let you know how I get on. cheers, Waider. -- wa...@gm... / It's about as impersonal as you can get. |
From: Ronan W. <wa...@gm...> - 2013-05-16 16:41:46
|
On 05/16/2013 03:15 PM, Ronan Waide wrote: > Thanks for that, John. I'll give it a whirl and let you know how I get > on. > > cheers, > Waider. > Couple of problems. Caveat, I've forced jhbuild back to 2.32.4 to get this far due to the current jhbuild head having a circular dependency on pkg-config. 1. libxml2 is required as a build dependency. Manually worked around this. 2. berkeleydb build fails as it tries to build in the source tree. berkeleydb-insource build fails because it does "cd build_unix; ./dist/configure" instead of "../dist/configure". Manually worked around this. 3. pil definitely seems to want a newer python than it's finding - it makes use of print() with an "end" named param,, which isn't supported in python2.7 - it's a python3.x-ism. *** Building pil *** [40/43] /Users/waider/gtk/inst/bin/python setup.py build File "setup.py", line 379 print("***", option[1], "support not available", end=' ') ^ SyntaxError: invalid syntax Hacking out the erroneous 'end=' gets me this: _imaging.c: In function 'getink': _imaging.c:490: warning: implicit declaration of function 'PyLong_AS_LONG' _imaging.c: At top level: _imaging.c:2898: warning: initialization from incompatible pointer type _imaging.c:3011: warning: initialization from incompatible pointer type _imaging.c:3181: error: variable '_imaging_module' has initializer but incomplete type _imaging.c:3182: error: 'PyModuleDef_HEAD_INIT' undeclared here (not in a function) As noted earlier I made this work yesterday by reverting the entire git repo for PIL to the point at which it forked, but your response to this suggested it should be building from a tarball, not a git repo, so I'm a bit concerned that I'm still pulling the wrong *something* here. In the meantime I've done the same trick again and ta-da, I have a build... which crashes, quite possibly because of the PIL hackery. One last thing, which definitely is a bug: two of the gramps .po files have newline mismatches (es.po and ru.po) which cause the build to break. I'll submit a bug & suggested patch for these. Cheers, Waider -- wa...@gm... / It's about as impersonal as you can get. |
From: John R. <jr...@ce...> - 2013-05-16 17:22:25
|
On May 16, 2013, at 9:41 AM, Ronan Waide <wa...@gm...> wrote: > On 05/16/2013 03:15 PM, Ronan Waide wrote: >> Thanks for that, John. I'll give it a whirl and let you know how I get on. >> >> cheers, >> Waider. >> > Couple of problems. Caveat, I've forced jhbuild back to 2.32.4 to get this far due to the current jhbuild head having a circular dependency on pkg-config. Roger. > 1. libxml2 is required as a build dependency. Manually worked around this. Libxml2 is supplied by meta-gtk-osx-bootstrap. > 2. berkeleydb build fails as it tries to build in the source tree. berkeleydb-insource build fails because it does "cd build_unix; ./dist/configure" instead of "../dist/configure". Manually worked around this. Hmm. I'll take a look at that. I should probably change the nomenclature around as well, since building in the source tree is more the default behavior for jhbuild. > 3. pil definitely seems to want a newer python than it's finding - it makes use of print() with an "end" named param,, which isn't supported in python2.7 - it's a python3.x-ism. > > *** Building pil *** [40/43] > /Users/waider/gtk/inst/bin/python setup.py build > File "setup.py", line 379 > print("***", option[1], "support not available", end=' ') > ^ > SyntaxError: invalid syntax > > Hacking out the erroneous 'end=' gets me this: > > _imaging.c: In function 'getink': > _imaging.c:490: warning: implicit declaration of function 'PyLong_AS_LONG' > _imaging.c: At top level: > _imaging.c:2898: warning: initialization from incompatible pointer type > _imaging.c:3011: warning: initialization from incompatible pointer type > _imaging.c:3181: error: variable '_imaging_module' has initializer but incomplete type > _imaging.c:3182: error: 'PyModuleDef_HEAD_INIT' undeclared here (not in a function) > > As noted earlier I made this work yesterday by reverting the entire git repo for PIL to the point at which it forked, but your response to this suggested it should be building from a tarball, not a git repo, so I'm a bit concerned that I'm still pulling the wrong *something* here. In the meantime I've done the same trick again and ta-da, I have a build... which crashes, quite possibly because of the PIL hackery. Didn't suggest. Said outright. The module says: <distutils id="pil"> <branch module="Imaging-1.1.7.tar.gz" version="1.1.7" repo="pythonware"/> <!--branch module="sloonz/pil-py3k.git" repo="github"/--> </distutils> Maybe you're still trying to build with gramps.modules from the old sourceforge repo? > > One last thing, which definitely is a bug: two of the gramps .po files have newline mismatches (es.po and ru.po) which cause the build to break. I'll submit a bug & suggested patch for these. Regards, John Ralls |
From: Ronan W. <wa...@gm...> - 2013-05-16 17:00:28
|
On 05/16/2013 03:12 PM, John Ralls wrote: > Don't do that. You do need everything in the meta packages. As for PIL, the tarball in gramps.modules (Imaging-1.1.7.tar.gz) is > correct for Python 2.7.2; since Python3 presents problems building GObject-introspection I'm not using it and the pil-py3k is commented out. Looks like it's the other way around: <distutils id="pil"> <!--branch module="Imaging-1.1.7.tar.gz" version="1.1.7" repo="pythonware"/--> <branch module="sloonz/pil-py3k.git" repo="github"/> </distutils> zippy:gramps-mac gramps$ svn info gramps.modules Path: gramps.modules Name: gramps.modules URL: http://svn.code.sf.net/p/gramps/code/trunk/mac/gramps.modules Repository Root: http://svn.code.sf.net/p/gramps/code Repository UUID: 4ae1f11a-8b86-4847-b8af-ab372f36d1fd Revision: 22327 Node Kind: file Schedule: normal Last Changed Author: jralls Last Changed Rev: 21271 Last Changed Date: 2013-02-01 20:25:35 +0000 (Fri, 01 Feb 2013) Text Last Updated: 2013-05-16 15:32:56 +0100 (Thu, 16 May 2013) Checksum: 835b5d777285e4b113b763762472b309 I'll fix this in place and see how the build goes. Cheers, Waider. -- wa...@gm... / It's about as impersonal as you can get. |
From: John R. <jr...@ce...> - 2013-05-16 17:31:58
|
On May 16, 2013, at 10:00 AM, Ronan Waide <wa...@gm...> wrote: > On 05/16/2013 03:12 PM, John Ralls wrote: >> Don't do that. You do need everything in the meta packages. As for PIL, the tarball in gramps.modules (Imaging-1.1.7.tar.gz) is >> correct for Python 2.7.2; since Python3 presents problems building GObject-introspection I'm not using it and the pil-py3k is commented out. > Looks like it's the other way around: > > <distutils id="pil"> > <!--branch module="Imaging-1.1.7.tar.gz" version="1.1.7" repo="pythonware"/--> > <branch module="sloonz/pil-py3k.git" repo="github"/> > </distutils> > > zippy:gramps-mac gramps$ svn info gramps.modules > Path: gramps.modules > Name: gramps.modules > URL: http://svn.code.sf.net/p/gramps/code/trunk/mac/gramps.modules > Repository Root: http://svn.code.sf.net/p/gramps/code > Repository UUID: 4ae1f11a-8b86-4847-b8af-ab372f36d1fd > Revision: 22327 > Node Kind: file > Schedule: normal > Last Changed Author: jralls > Last Changed Rev: 21271 > Last Changed Date: 2013-02-01 20:25:35 +0000 (Fri, 01 Feb 2013) > Text Last Updated: 2013-05-16 15:32:56 +0100 (Thu, 16 May 2013) > Checksum: 835b5d777285e4b113b763762472b309 > > I'll fix this in place and see how the build goes. Sorry, this is entirely my fault. I have a rather large change to gramps.modules that's been sitting in my working directory, probably for months. I just committed it. You should update and start over. Regards, John Ralls |
From: Ronan W. <wa...@gm...> - 2013-05-16 18:41:16
|
On 16 May 2013, at 18:31, John Ralls <jr...@ce...> wrote: > > On May 16, 2013, at 10:00 AM, Ronan Waide <wa...@gm...> wrote: > >> On 05/16/2013 03:12 PM, John Ralls wrote: >>> Don't do that. You do need everything in the meta packages. As for PIL, the tarball in gramps.modules (Imaging-1.1.7.tar.gz) is >>> correct for Python 2.7.2; since Python3 presents problems building GObject-introspection I'm not using it and the pil-py3k is commented out. >> Looks like it's the other way around: >> >> <distutils id="pil"> >> <!--branch module="Imaging-1.1.7.tar.gz" version="1.1.7" repo="pythonware"/--> >> <branch module="sloonz/pil-py3k.git" repo="github"/> >> </distutils> >> >> zippy:gramps-mac gramps$ svn info gramps.modules >> Path: gramps.modules >> Name: gramps.modules >> URL: http://svn.code.sf.net/p/gramps/code/trunk/mac/gramps.modules >> Repository Root: http://svn.code.sf.net/p/gramps/code >> Repository UUID: 4ae1f11a-8b86-4847-b8af-ab372f36d1fd >> Revision: 22327 >> Node Kind: file >> Schedule: normal >> Last Changed Author: jralls >> Last Changed Rev: 21271 >> Last Changed Date: 2013-02-01 20:25:35 +0000 (Fri, 01 Feb 2013) >> Text Last Updated: 2013-05-16 15:32:56 +0100 (Thu, 16 May 2013) >> Checksum: 835b5d777285e4b113b763762472b309 >> >> I'll fix this in place and see how the build goes. > > Sorry, this is entirely my fault. I have a rather large change to gramps.modules that's been sitting in my working directory, probably for months. I just committed it. You should update and start over. > Not quite there yet (as ever, I can hack this in place): jhbuild build: failed to parse /Users/john/Development/GTK-OSX/gtk-osx-build/modulesets-stable/gtk-osx.modules: [Errno 2] No such file or directory: u'/Users/john/Development/GTK-OSX/gtk-osx-build/modulesets-stable/gtk-osx.modules' Cheers, Waider. -- wa...@gm... / It's about as impersonal as you can get. |
From: John R. <jr...@ce...> - 2013-05-16 19:25:54
|
On May 16, 2013, at 11:41 AM, Ronan Waide <wa...@gm...> wrote: > Not quite there yet (as ever, I can hack this in place): > > jhbuild build: failed to parse /Users/john/Development/GTK-OSX/gtk-osx-build/modulesets-stable/gtk-osx.modules: [Errno 2] No such file or directory: u'/Users/john/Development/GTK-OSX/gtk-osx-build/modulesets-stable/gtk-osx.modules' Sigh. Committed. Thanks. Regards, John Ralls |
From: Ronan W. <wa...@gm...> - 2013-05-16 21:41:29
|
On 16 May 2013, at 20:25, John Ralls <jr...@ce...> wrote: > > On May 16, 2013, at 11:41 AM, Ronan Waide <wa...@gm...> wrote: > >> Not quite there yet (as ever, I can hack this in place): >> >> jhbuild build: failed to parse /Users/john/Development/GTK-OSX/gtk-osx-build/modulesets-stable/gtk-osx.modules: [Errno 2] No such file or directory: u'/Users/john/Development/GTK-OSX/gtk-osx-build/modulesets-stable/gtk-osx.modules' > > > Sigh. Committed. Thanks. > > Regards, > John Ralls > and one more: jhbuild build: failed to parse /Users/john/Development/GTK-OSX/gtk-osx-build/modulesets-stable/gtk-osx.modules: [Errno 2] No such file or directory: u'/Users/john/Development/GTK-OSX/gtk-osx-build/modulesets-stable/gtk-osx.modules' (sorry I didn't point this out sooner - been away from the keyboard…) cheers, Waider. -- wa...@gm... / It's about as impersonal as you can get. |
From: John R. <jr...@ce...> - 2013-05-16 22:48:06
|
On May 16, 2013, at 2:41 PM, Ronan Waide <wa...@gm...> wrote: > > On 16 May 2013, at 20:25, John Ralls <jr...@ce...> wrote: > >> >> On May 16, 2013, at 11:41 AM, Ronan Waide <wa...@gm...> wrote: >> >>> Not quite there yet (as ever, I can hack this in place): >>> >>> jhbuild build: failed to parse /Users/john/Development/GTK-OSX/gtk-osx-build/modulesets-stable/gtk-osx.modules: [Errno 2] No such file or directory: u'/Users/john/Development/GTK-OSX/gtk-osx-build/modulesets-stable/gtk-osx.modules' >> >> >> Sigh. Committed. Thanks. >> >> Regards, >> John Ralls >> > > and one more: > jhbuild build: failed to parse /Users/john/Development/GTK-OSX/gtk-osx-build/modulesets-stable/gtk-osx.modules: [Errno 2] No such file or directory: u'/Users/john/Development/GTK-OSX/gtk-osx-build/modulesets-stable/gtk-osx.modules' > > (sorry I didn't point this out sooner - been away from the keyboard…) That's the same error, which I think I committed a fix for. Are you sure that you updated before trying again? Regards, John Ralls |
From: John R. <jr...@ce...> - 2013-05-17 06:15:23
|
On May 16, 2013, at 3:54 PM, Ronan Waide <wa...@gm...> wrote: > Sorry, cut and paste mishap. There's a patch file referenced in the module sets file as well. OK, fixed, along with the "\n" errors in the two po files. I guess I should have mentioned sooner that there's some sort of interaction between gtk and pygobject that causes a crash when built with XCode 4 and the 10.8 SDK: Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 ??? 0x7c497c90 0 + 2085190800 1 libgobject-2.0.0.dylib 0x01f87a35 g_type_class_meta_marshal + 69 2 libgobject-2.0.0.dylib 0x01f8869b g_closure_invoke + 315 3 libgobject-2.0.0.dylib 0x01f9855c signal_emit_unlocked_R + 2124 4 libgobject-2.0.0.dylib 0x01f99491 g_signal_emit_valist + 3089 5 libgobject-2.0.0.dylib 0x01f99a29 g_signal_emit + 41 6 libgtk-3.0.dylib 0x026bc796 gtk_text_buffer_set_mark + 262 7 libgtk-3.0.dylib 0x026bcbc6 gtk_text_buffer_create_mark + 134 8 libffi.6.dylib 0x0223e9dd .LCFI1 + 26 (darwin.S:67) 9 libffi.6.dylib 0x0223e999 ffi_call + 137 (ffi.c:413) 10 libgirepository-1.0.1.dylib 0x01f514a5 g_callable_info_invoke + 1013 11 libgirepository-1.0.1.dylib 0x01f52843 g_function_info_invoke + 339 12 _gi.so 0x01f33e01 pygi_callable_info_invoke + 2465 13 _gi.so 0x01f3422a _wrap_g_callable_info_invoke + 90 14 libpython2.7.dylib 0x0006052c PyCFunction_Call + 92 (methodobject.c:81) 15 libpython2.7.dylib 0x000b92ce PyEval_EvalFrameEx + 17390 (ceval.c:4331) 16 libpython2.7.dylib 0x000bb71d PyEval_EvalCodeEx + 1885 (ceval.c:3253) 17 libpython2.7.dylib 0x0004b35b function_call + 331 (funcobject.c:526) 18 libpython2.7.dylib 0x000220b1 PyObject_Call + 97 (abstract.c:2530) 19 libpython2.7.dylib 0x00033e4e instancemethod_call + 510 (classobject.c:2579) 20 libpython2.7.dylib 0x000220b1 PyObject_Call + 97 (abstract.c:2530) 21 libpython2.7.dylib 0x000b8d39 PyEval_EvalFrameEx + 15961 (ceval.c:4239) 22 libpython2.7.dylib 0x000bb71d PyEval_EvalCodeEx + 1885 (ceval.c:3253) I've been avoiding the problem by building with XCode3. I'll be interested to learn if you encounter the same problem with the 10.7 SDK. You might try the 10.6 SDK if you have it available. Regards, John Ralls |
From: Ronan W. <wa...@gm...> - 2013-05-17 11:14:21
|
On 05/17/2013 07:14 AM, John Ralls wrote: > I've been avoiding the problem by building with XCode3. I'll be interested to learn if you encounter the same problem > with the 10.7 SDK. You might try the 10.6 SDK if you have it available. Hit the problem and couldn't (quickly) see a cause; I'll try the earlier SDK and see what happens. The berkeleydb build still requires the manual attention I mentioned yesterday. Seems like the "-insource" version uses $srcdir/dist but $srcdir is set to ".", so you wind up with ./dist, which doesn't exist if you're in the build_unix directory (should be ../dist) Cheers, Waider. -- wa...@gm... / It's about as impersonal as you can get. |
From: John R. <jr...@ce...> - 2013-05-17 17:23:00
|
On May 17, 2013, at 4:14 AM, Ronan Waide <wa...@gm...> wrote: > On 05/17/2013 07:14 AM, John Ralls wrote: >> I've been avoiding the problem by building with XCode3. I'll be interested to learn if you encounter the same problem >> with the 10.7 SDK. You might try the 10.6 SDK if you have it available. > Hit the problem and couldn't (quickly) see a cause; I'll try the earlier SDK and see what happens. > > The berkeleydb build still requires the manual attention I mentioned yesterday. Seems like the "-insource" version uses $srcdir/dist but $srcdir is set to ".", so you wind up with ./dist, which doesn't exist if you're in the build_unix directory (should be ../dist) Yeah, I had though that $(srcdir) would do something sensible instead of hardcoding to '.' in srctree builds. Oh well. Fixed. I also switched the nomenclature around so that you'll want to use berkeleydb instead of berkeleydb-insource; I figure that it's more common to build in the source tree, since it's the default. Regards, John Ralls |
From: Ronan W. <wa...@gm...> - 2013-05-18 08:38:43
|
After some abuse of my local environment I got Xcode4 building with the 10.6 SDE, but the same stack trace bug occurs, so it looks like it's a compiler issue rather than a SDK issue. Guess ill have to debug that after all... -- wa...@wa... / Sent from my Internet On 2013-05-17, at 12:14, Ronan Waide <wa...@gm...> wrote: > On 05/17/2013 07:14 AM, John Ralls wrote: >> I've been avoiding the problem by building with XCode3. I'll be interested to learn if you encounter the same problem >> with the 10.7 SDK. You might try the 10.6 SDK if you have it available. > Hit the problem and couldn't (quickly) see a cause; I'll try the earlier SDK and see what happens. > > The berkeleydb build still requires the manual attention I mentioned yesterday. Seems like the "-insource" version uses $srcdir/dist but $srcdir is set to ".", so you wind up with ./dist, which doesn't exist if you're in the build_unix directory (should be ../dist) > > Cheers, > Waider. > > -- > wa...@gm... / It's about as impersonal as you can get. > |
From: Guilherme B. T. <gui...@gm...> - 2013-05-18 14:55:14
|
On 17/05/13 19:22, John Ralls wrote: > > On May 17, 2013, at 4:14 AM, Ronan Waide <wa...@gm...> wrote: > >> >> The berkeleydb build still requires the manual attention I mentioned yesterday. Seems like the "-insource" version uses $srcdir/dist but $srcdir is set to ".", so you wind up with ./dist, which doesn't exist if you're in the build_unix directory (should be ../dist) > > Yeah, I had though that $(srcdir) would do something sensible instead of hardcoding > to '.' in srctree builds. Oh well. Fixed. I also switched the nomenclature around > so that you'll want to use berkeleydb instead of berkeleydb-insource; I figure that > it's more common to build in the source tree, since it's the default. > > Regards, > John Ralls > Hi, I'm glad I found this thread. I'm also trying to compile Gramps on MacOS. I wrote the steps I did, the problems and partial solutions in here: https://gist.github.com/guitorri/5604523 Would you please have a look on it? It is bit more step-by-step then the info on the wiki. I found 4 issues so far. The last one I don't know how to get past. 1) berkeleydb still doesn't like the two commands in one line. --> solved my building manually 2) shared-mime-info is complaining about a missing file --> solved after rerun 3) unable to connect to the svn --> solved by changing the gramps-svn address on gramps.modules 4) Everything builds ok, but I can't start gramps. It looks like a path is wrong... ~ $ jhbuild shell Prefix: /Users/guilherme/gtk/inst Entered jhbuild shell, type 'exit' to return. ~ $ gramps ResourcePath.ERROR: Resource Path /Users/guilherme/gtk/inst/_jhbuild/root-gramps-svn/Users/guilherme/gtk/inst/share is invalid ~ $ ls gtk/inst/_jhbuild/ manifests packagedb.xml Thanks in advance for any help! Regards, Guilherme |
From: John R. <jr...@ce...> - 2013-05-18 16:19:17
|
On May 18, 2013, at 7:46 AM, Guilherme Brondani Torri <gui...@gm...> wrote: > > On 17/05/13 19:22, John Ralls wrote: >> >> On May 17, 2013, at 4:14 AM, Ronan Waide <wa...@gm...> wrote: >> >>> >>> The berkeleydb build still requires the manual attention I mentioned yesterday. Seems like the "-insource" version uses $srcdir/dist but $srcdir is set to ".", so you wind up with ./dist, which doesn't exist if you're in the build_unix directory (should be ../dist) >> >> Yeah, I had though that $(srcdir) would do something sensible instead of hardcoding >> to '.' in srctree builds. Oh well. Fixed. I also switched the nomenclature around >> so that you'll want to use berkeleydb instead of berkeleydb-insource; I figure that >> it's more common to build in the source tree, since it's the default. >> >> Regards, >> John Ralls >> > > Hi, I'm glad I found this thread. > I'm also trying to compile Gramps on MacOS. > > I wrote the steps I did, the problems and partial solutions in here: > https://gist.github.com/guitorri/5604523 > > Would you please have a look on it? It is bit more step-by-step then the info on the wiki. > > I found 4 issues so far. The last one I don't know how to get past. > > 1) berkeleydb still doesn't like the two commands in one line. > --> solved my building manually What's the actual error here? What shell (bash, tcsh, ...) are you using? > 2) shared-mime-info is complaining about a missing file > --> solved after rerun I've noticed this once or twice, but it isn't consistent enough to figure out what's going on. > 3) unable to connect to the svn > --> solved by changing the gramps-svn address on gramps.modules You've got an old version of gramps.modules. Where did you get it? > > 4) Everything builds ok, but I can't start gramps. It looks like a path is wrong... > > ~ $ jhbuild shell > Prefix: /Users/guilherme/gtk/inst > Entered jhbuild shell, type 'exit' to return. > ~ $ gramps > ResourcePath.ERROR: Resource Path /Users/guilherme/gtk/inst/_jhbuild/root-gramps-svn/Users/guilherme/gtk/inst/share is invalid > ~ $ ls gtk/inst/_jhbuild/ > manifests packagedb.xml > To fix the startup problem, cd to ~/gtk/src/gramps-svn and run python setup.py install which should re-write the ResourcePath without the jhbuild noise. Note that if you're going to work on Gramps you'll want to just run python Gramps.py from the source directory so you don't have an install in your write-test loop. What version of XCode and which SDK are you building with? Regards, John Ralls |
From: John R. <jr...@ce...> - 2013-05-18 16:22:26
|
On May 18, 2013, at 1:38 AM, Ronan Waide <wa...@gm...> wrote: > After some abuse of my local environment I got Xcode4 building with the 10.6 SDE, but the same stack trace bug occurs, so it looks like it's a compiler issue rather than a SDK issue. Guess ill have to debug that after all... If you can figure it out, that would be awesome. If you can't, you can install XCode3 [1] Regards, John Ralls [1] https://live.gnome.org/GTK%2B/OSX/Building#Installing_XCode_3_on_XCode_4_systems |
From: Guilherme B. T. <gui...@gm...> - 2013-05-18 19:11:21
|
On 18/05/13 18:19, John Ralls wrote: > On May 18, 2013, at 7:46 AM, Guilherme Brondani Torri <gui...@gm...> wrote: > > > 1) berkeleydb still doesn't like the two commands in one line. > --> solved my building manually > What's the actual error here? What shell (bash, tcsh, ...) are you using? I'm using a standard Terminal with bash, but jhbuild is running sh, no? I don't get it. I just started the shell and copied the command as written below and it went ok. ~ $ jhbuild build berkeleydb --force *** Checking out berkeleydb *** [1/1] *** Configuring berkeleydb *** [1/1] cd build_unix; ../dist/configure --prefix /Users/guilherme/gtk/inst --libdir '/Users/guilherme/gtk/inst/lib' /bin/sh: ../dist/configure: No such file or directory *** Error during phase configure of berkeleydb: ########## Error running cd build_unix; ../dist/configure --prefix /Users/guilherme/gtk/inst --libdir '/Users/guilherme/gtk/inst/lib' *** [1/1] >> 3) unable to connect to the svn >> --> solved by changing the gramps-svn address on gramps.modules > You've got an old version of gramps.modules. Where did you get it? From the wiki: http://www.gramps-project.org/wiki/index.php?title=Mac_OS_X:Build_from_source:Application_package I checked : svn co https://svn.code.sf.net/p/gramps/code/branches/maintenance/gramps40/mac gramps-mac >> 4) Everything builds ok, but I can't start gramps. It looks like a path is wrong... >> >> ~ $ jhbuild shell >> Prefix: /Users/guilherme/gtk/inst >> Entered jhbuild shell, type 'exit' to return. >> ~ $ gramps >> ResourcePath.ERROR: Resource Path /Users/guilherme/gtk/inst/_jhbuild/root-gramps-svn/Users/guilherme/gtk/inst/share is invalid >> ~ $ ls gtk/inst/_jhbuild/ >> manifests packagedb.xml >> > To fix the startup problem, cd to ~/gtk/src/gramps-svn and run > python setup.py install > which should re-write the ResourcePath without the jhbuild noise. Note that if you're going to work on > Gramps you'll want to just run > python Gramps.py > from the source directory so you don't have an install in your write-test loop. Thanks. I'm now also having the pyobject crash... > > What version of XCode and which SDK are you building with? I have XCode 4.6.3 and SKD 10.7 and 10.8. Ronan Waine mentioned that the pyobject crash also happens with 10.6 After I get XCode 3 and SDK 10.5, and set the 'setup_sdk' on my .jhbuild-custom, what else I need to do? Which modules do I have to rebuild? Regards, Guilherme |
From: Guilherme B. T. <gui...@gm...> - 2013-05-18 19:21:28
|
On 18/05/13 21:11, Guilherme Brondani Torri wrote: >>> >> To fix the startup problem, cd to ~/gtk/src/gramps-svn and run >> python setup.py install >> which should re-write the ResourcePath without the jhbuild noise. Note that if you're going to work on >> Gramps you'll want to just run >> python Gramps.py >> from the source directory so you don't have an install in your write-test loop. > Thanks. I'm now also having the pyobject crash... >> Just adding to the above error. Before the pyobject crash the terminal shows the following. It didn't install 'pango.modules', it is still on the source directory: ~/gtk/source/gramps-svn $ python Gramps.py grampslocale.DEBUG: Ended check for languages with glocale.language ['en'] grampslocale.DEBUG: Setting encoding to UTF-8 (Gramps.py:94206): Pango-CRITICAL **: No modules found: No builtin or dynamically loaded modules were found. PangoFc will not work correctly. This probably means there was an error in the creation of: '/Users/guilherme/gtk/inst/etc/pango/pango.modules' You should create this file by running: pango-querymodules > '/Users/guilherme/gtk/inst/etc/pango/pango.modules' (Gramps.py:94206): Pango-WARNING **: failed to choose a font, expect ugly output. engine-type='PangoRenderCoreText', script='common' (Gramps.py:94206): Pango-WARNING **: failed to choose a font, expect ugly output. engine-type='PangoRenderCoreText', script='latin' 2013-05-18 21:11:48.844: WARNING: htmlrenderer.gpr.py: line 62: Webkit module not loaded. Embedded web page viewing will not be available. Use your package manager to install gir1.2-webkit-3.0 Bus error: 10 ~/gtk/source/gramps-svn $ find ~/gtk -name pango.modules /Users/guilherme/gtk/source/pango-1.34.0/modules/pango.modules Regards, Guilherme |
From: John R. <jr...@ce...> - 2013-05-18 19:42:21
|
On May 18, 2013, at 12:11 PM, Guilherme Brondani Torri <gui...@gm...> wrote: > On 18/05/13 18:19, John Ralls wrote: >> On May 18, 2013, at 7:46 AM, Guilherme Brondani Torri <gui...@gm...> wrote: >> >> >> 1) berkeleydb still doesn't like the two commands in one line. >> --> solved my building manually >> What's the actual error here? What shell (bash, tcsh, ...) are you using? > I'm using a standard Terminal with bash, but jhbuild is running sh, no? > I don't get it. I just started the shell and copied the command as written below and it went ok. > > ~ $ jhbuild build berkeleydb --force > *** Checking out berkeleydb *** [1/1] > *** Configuring berkeleydb *** [1/1] > cd build_unix; ../dist/configure --prefix /Users/guilherme/gtk/inst --libdir '/Users/guilherme/gtk/inst/lib' > /bin/sh: ../dist/configure: No such file or directory > *** Error during phase configure of berkeleydb: ########## Error running cd build_unix; ../dist/configure --prefix /Users/guilherme/gtk/inst --libdir '/Users/guilherme/gtk/inst/lib' *** [1/1] Hmm. I'll poke at that a bit. >>> 3) unable to connect to the svn >>> --> solved by changing the gramps-svn address on gramps.modules >> You've got an old version of gramps.modules. Where did you get it? > From the wiki: > http://www.gramps-project.org/wiki/index.php?title=Mac_OS_X:Build_from_source:Application_package > > I checked : > svn co https://svn.code.sf.net/p/gramps/code/branches/maintenance/gramps40/mac gramps-mac Ah, they're out of sync. I'll fix that in a bit. In the meantime, you should get https://svn.code.sf.net/p/gramps/code/trunk/mac instead. > >>> 4) Everything builds ok, but I can't start gramps. It looks like a path is wrong... >>> >>> ~ $ jhbuild shell >>> Prefix: /Users/guilherme/gtk/inst >>> Entered jhbuild shell, type 'exit' to return. >>> ~ $ gramps >>> ResourcePath.ERROR: Resource Path /Users/guilherme/gtk/inst/_jhbuild/root-gramps-svn/Users/guilherme/gtk/inst/share is invalid >>> ~ $ ls gtk/inst/_jhbuild/ >>> manifests packagedb.xml >>> >> To fix the startup problem, cd to ~/gtk/src/gramps-svn and run >> python setup.py install >> which should re-write the ResourcePath without the jhbuild noise. Note that if you're going to work on >> Gramps you'll want to just run >> python Gramps.py >> from the source directory so you don't have an install in your write-test loop. > Thanks. I'm now also having the pyobject crash... >> >> What version of XCode and which SDK are you building with? > I have XCode 4.6.3 and SKD 10.7 and 10.8. > Ronan Waine mentioned that the pyobject crash also happens with 10.6 > > After I get XCode 3 and SDK 10.5, and set the 'setup_sdk' on my .jhbuild-custom, > what else I need to do? > Which modules do I have to rebuild? I recommend starting from scratch. Regards, John Ralls |
From: John R. <jr...@ce...> - 2013-05-18 20:20:22
|
On May 18, 2013, at 12:11 PM, Guilherme Brondani Torri <gui...@gm...> wrote: > On 18/05/13 18:19, John Ralls wrote: >> On May 18, 2013, at 7:46 AM, Guilherme Brondani Torri <gui...@gm...> wrote: >> >> >> 1) berkeleydb still doesn't like the two commands in one line. >> --> solved my building manually >> What's the actual error here? What shell (bash, tcsh, ...) are you using? > I'm using a standard Terminal with bash, but jhbuild is running sh, no? > I don't get it. I just started the shell and copied the command as written below and it went ok. > > ~ $ jhbuild build berkeleydb --force > *** Checking out berkeleydb *** [1/1] > *** Configuring berkeleydb *** [1/1] > cd build_unix; ../dist/configure --prefix /Users/guilherme/gtk/inst --libdir '/Users/guilherme/gtk/inst/lib' > /bin/sh: ../dist/configure: No such file or directory > *** Error during phase configure of berkeleydb: ########## Error running cd build_unix; ../dist/configure --prefix /Users/guilherme/gtk/inst --libdir '/Users/guilherme/gtk/inst/lib' *** [1/1] >> It turns out that jhbuild was ignoring the 'cd'. Adding a ';' in front so that cd was the second command works, so I've made that change. Oddly, if the first command is something that just prints and exits, the output shows up, so jhbuild must be doing something special. I'll have to pull on that string a bit, but the issue here is dealt with: The change is pushed. Regards, John Ralls |
From: Ronan W. <wa...@gm...> - 2013-05-23 16:58:40
|
On 05/18/2013 05:22 PM, John Ralls wrote: > On May 18, 2013, at 1:38 AM, Ronan Waide <wa...@gm...> wrote: > >> After some abuse of my local environment I got Xcode4 building with the 10.6 SDE, but the same stack trace bug occurs, so it looks like it's a compiler issue rather than a SDK issue. Guess ill have to debug that after all... > If you can figure it out, that would be awesome. If you can't, you can install XCode3 [1] > > Regards, > John Ralls > > [1] https://live.gnome.org/GTK%2B/OSX/Building#Installing_XCode_3_on_XCode_4_systems > I've been looking at this a bit, but I've also been sidetracked by other things. Anyway, I got back to running a scratch-build today, and it's throwing this: libtool: Version mismatch error. This is libtool 2.4.2, but the libtool: definition of this LT_INIT comes from libtool 2.4. libtool: You should recreate aclocal.m4 with macros from libtool 2.4.2 libtool: and run autoconf again. make[3]: *** [fcatomic.lo] Error 63 make[3]: *** Waiting for unfinished jobs.... libtool: Version mismatch error. This is libtool 2.4.2, but the libtool: definition of this LT_INIT comes from libtool 2.4. libtool: You should recreate aclocal.m4 with macros from libtool 2.4.2 libtool: and run autoconf again. libtool: Version mismatch error. This is libtool 2.4.2, but the libtool: definition of this LT_INIT comes from libtool 2.4. libtool: You should recreate aclocal.m4 with macros from libtool 2.4.2 libtool: and run autoconf again. make[3]: *** [fccache.lo] Error 63 make[3]: *** [fcblanks.lo] Error 63 make[2]: *** [all] Error 2 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 *** Error during phase build of fontconfig: ########## Error running make -j 3 *** [18/57] This is with the new jhbuild that's pulled from master. I had a build running elsewhere using the 2.32.4 version that doesn't exhibit this. Cheers, Waider. -- wa...@gm... / It's about as impersonal as you can get. |
From: John R. <jr...@ce...> - 2013-05-23 19:14:09
|
On May 23, 2013, at 9:58 AM, Ronan Waide <wa...@gm...> wrote: > On 05/18/2013 05:22 PM, John Ralls wrote: >> On May 18, 2013, at 1:38 AM, Ronan Waide <wa...@gm...> wrote: >> >>> After some abuse of my local environment I got Xcode4 building with the 10.6 SDE, but the same stack trace bug occurs, so it looks like it's a compiler issue rather than a SDK issue. Guess ill have to debug that after all... >> If you can figure it out, that would be awesome. If you can't, you can install XCode3 [1] >> >> Regards, >> John Ralls >> >> [1] https://live.gnome.org/GTK%2B/OSX/Building#Installing_XCode_3_on_XCode_4_systems >> > I've been looking at this a bit, but I've also been sidetracked by other things. Anyway, I got back to running a scratch-build today, and it's throwing this: > > libtool: Version mismatch error. This is libtool 2.4.2, but the > libtool: definition of this LT_INIT comes from libtool 2.4. > libtool: You should recreate aclocal.m4 with macros from libtool 2.4.2 > libtool: and run autoconf again. > make[3]: *** [fcatomic.lo] Error 63 > make[3]: *** Waiting for unfinished jobs.... > libtool: Version mismatch error. This is libtool 2.4.2, but the > libtool: definition of this LT_INIT comes from libtool 2.4. > libtool: You should recreate aclocal.m4 with macros from libtool 2.4.2 > libtool: and run autoconf again. > libtool: Version mismatch error. This is libtool 2.4.2, but the > libtool: definition of this LT_INIT comes from libtool 2.4. > libtool: You should recreate aclocal.m4 with macros from libtool 2.4.2 > libtool: and run autoconf again. > make[3]: *** [fccache.lo] Error 63 > make[3]: *** [fcblanks.lo] Error 63 > make[2]: *** [all] Error 2 > make[1]: *** [all-recursive] Error 1 > make: *** [all] Error 2 > *** Error during phase build of fontconfig: ########## Error running make -j 3 *** [18/57] > > > This is with the new jhbuild that's pulled from master. I had a build running elsewhere using the 2.32.4 version that doesn't exhibit this. That's https://bugzilla.gnome.org/show_bug.cgi?id=700557 I recommend that you make the edit proposed in the bug report. Regards, John Ralls |
From: Ronan W. <wa...@gm...> - 2013-05-24 11:16:30
|
On 05/23/2013 08:13 PM, John Ralls wrote: > On May 23, 2013, at 9:58 AM, Ronan Waide <wa...@gm...> wrote: > >> On 05/18/2013 05:22 PM, John Ralls wrote: >>> On May 18, 2013, at 1:38 AM, Ronan Waide <wa...@gm...> wrote: >>> >>>> After some abuse of my local environment I got Xcode4 building with the 10.6 SDE, but the same stack trace bug occurs, so it looks like it's a compiler issue rather than a SDK issue. Guess ill have to debug that after all... >>> If you can figure it out, that would be awesome. If you can't, you can install XCode3 [1] >>> >>> Regards, >>> John Ralls >>> >>> [1] https://live.gnome.org/GTK%2B/OSX/Building#Installing_XCode_3_on_XCode_4_systems >>> >> I've been looking at this a bit, but I've also been sidetracked by other things. Anyway, I got back to running a scratch-build today, and it's throwing this: >> >> libtool: Version mismatch error. This is libtool 2.4.2, but the >> libtool: definition of this LT_INIT comes from libtool 2.4. >> libtool: You should recreate aclocal.m4 with macros from libtool 2.4.2 >> libtool: and run autoconf again. >> make[3]: *** [fcatomic.lo] Error 63 >> make[3]: *** Waiting for unfinished jobs.... >> libtool: Version mismatch error. This is libtool 2.4.2, but the >> libtool: definition of this LT_INIT comes from libtool 2.4. >> libtool: You should recreate aclocal.m4 with macros from libtool 2.4.2 >> libtool: and run autoconf again. >> libtool: Version mismatch error. This is libtool 2.4.2, but the >> libtool: definition of this LT_INIT comes from libtool 2.4. >> libtool: You should recreate aclocal.m4 with macros from libtool 2.4.2 >> libtool: and run autoconf again. >> make[3]: *** [fccache.lo] Error 63 >> make[3]: *** [fcblanks.lo] Error 63 >> make[2]: *** [all] Error 2 >> make[1]: *** [all-recursive] Error 1 >> make: *** [all] Error 2 >> *** Error during phase build of fontconfig: ########## Error running make -j 3 *** [18/57] >> >> >> This is with the new jhbuild that's pulled from master. I had a build running elsewhere using the 2.32.4 version that doesn't exhibit this. > That's > https://bugzilla.gnome.org/show_bug.cgi?id=700557 > > I recommend that you make the edit proposed in the bug report. > > Regards, > John Ralls > Applied that, reran clean build, now getting this: *** Configuring gtkspell3 *** [40/57] autoreconf -fi aclocal: error: couldn't open directory 'm4': No such file or directory autoreconf: aclocal failed with exit status: 1 *** Error during phase configure of gtkspell3: ########## Error running autoreconf -fi *** [40/57] Cheers, Waider. -- wa...@gm... / It's about as impersonal as you can get. |