From: Ronan W. <wa...@gm...> - 2013-09-19 07:01:16
|
Hi folks (mainly John, I guess!), I've pulled together the build instructions for the Mac version of Gramps into a script which will automatically produce both the application bundle and the .dmg file from the current trunk. Would anyone be interested in me automating this to generate nightly builds? Obviously I'd have to flag them as developer builds, etc. Cheers, Waider -- wa...@gm... / It's about as impersonal as you can get. |
From: Vassilii K. <vas...@ta...> - 2013-09-20 09:15:28
|
On 19.09.2013 10:01, Ronan Waide wrote: > Hi folks (mainly John, I guess!), > > I've pulled together the build instructions for the Mac version of Gramps into a script which will automatically produce both the application bundle and the .dmg file from the current trunk. Would anyone be interested in me automating this to generate nightly builds? Obviously I'd have to flag them as developer builds, etc. > > Cheers, > Waider Do we even have a server where we could run and host the nightly builds? I'd love to have a nightly test run in each branch, too! |
From: Ronan W. <wa...@gm...> - 2013-09-20 09:29:50
|
On 09/20/2013 10:15 AM, Vassilii Khachaturov wrote: > On 19.09.2013 10:01, Ronan Waide wrote: >> Hi folks (mainly John, I guess!), >> >> I've pulled together the build instructions for the Mac version of Gramps into a script which will automatically produce both the application bundle and the .dmg file from the current trunk. Would anyone be interested in me automating this to generate nightly builds? Obviously I'd have to flag them as developer builds, etc. >> >> Cheers, >> Waider > Do we even have a server where we could run and host the nightly builds? > I'd love to have a nightly test run in each branch, too! > > I can put the nightly Mac builds on my own webserver on a trial basis to see what sort of cost it incurs. I'm using Amazon Web Services, so if it turns out to be too expensive I'll figure out some way of restricting it. We could probably drop nightly builds into a directory on sourceforge, mind you. Cheers, Waider. -- wa...@gm... / It's about as impersonal as you can get. |
From: Vassilii K. <vas...@ta...> - 2013-09-20 09:39:25
|
On 20.09.2013 12:29, Ronan Waide wrote: > > I can put the nightly Mac builds on my own webserver on a trial basis > to see what sort of cost it incurs. I'm using Amazon Web Services, so > if it turns out to be too expensive I'll figure out some way of > restricting it. We could probably drop nightly builds into a directory > on sourceforge, mind you. > Sounds great, thanks for willing to try it out! v |
From: Ronan W. <wa...@gm...> - 2013-09-20 10:35:05
|
On 09/20/2013 10:39 AM, Vassilii Khachaturov wrote: > On 20.09.2013 12:29, Ronan Waide wrote: >> >> I can put the nightly Mac builds on my own webserver on a trial basis >> to see what sort of cost it incurs. I'm using Amazon Web Services, so >> if it turns out to be too expensive I'll figure out some way of >> restricting it. We could probably drop nightly builds into a >> directory on sourceforge, mind you. >> > Sounds great, thanks for willing to try it out! > v http://www.waider.ie/gramps/Gramps-Intel-trunk-r22913.dmg As this is the first one of these I've put together, a couple of notes are in order - I should include these in an extra README file, possibly one that opens automatically when you mount the disk. * The build is from trunk, SVN revision 22913, as indicated in the filename. The build script should allow me to provide arbitrary branch builds, but I haven't tested that. * The build is for Intel, and may possibly be 64-bit only - I've not checked this. * This was built on MacOS 10.7 to avoid the problems we've seen with low-level pygobject crashes using XCode4 on 10.8. I don't yet have a working 10.8.5 environment to see if this bug still exists, but I know that a 10.7 build will at least not crash on startup! * I'm not a registered Apple developer, so the binary isn't signed, which means you have to right-click and select 'Open' to launch the app, unless you've configured MacOS to ignore application signatures. * I've done no real testing on this other than verifying that I can run it and open an existing tree (with accompanying warnings about upgrading the database, etc.) * I've made some minor changes to the build to allow it to build; this includes updating the bundler file, and fixing the resourcepath issue. I know John's aware of the latter, not sure about the former since it only matters when you're trying to build the finished application. In any case, I can file a bug and offer a patch. I'd appreciate if any Mac users lurking on the list, developer or otherwise, could give this a spin and let me know if it works for them. DO NOT FEED THIS ANY DATA YOU CARE ABOUT WITHOUT BACKING UP FIRST. It's a developer release, it will possibly contain bugs. Oh, and as noted, if my hosting costs suddenly skyrocket I'll be removing this build. In any case, since the URL is based on the SVN revision it has a limited lifetime :) Cheers, Waider -- wa...@gm... / It's about as impersonal as you can get. |
From: John R. <jr...@ce...> - 2013-09-20 13:41:55
|
On Sep 20, 2013, at 3:34 AM, Ronan Waide <wa...@gm...> wrote: > On 09/20/2013 10:39 AM, Vassilii Khachaturov wrote: >> On 20.09.2013 12:29, Ronan Waide wrote: >>> >>> I can put the nightly Mac builds on my own webserver on a trial basis >>> to see what sort of cost it incurs. I'm using Amazon Web Services, so >>> if it turns out to be too expensive I'll figure out some way of >>> restricting it. We could probably drop nightly builds into a >>> directory on sourceforge, mind you. >>> >> Sounds great, thanks for willing to try it out! >> v > > http://www.waider.ie/gramps/Gramps-Intel-trunk-r22913.dmg > > As this is the first one of these I've put together, a couple of notes > are in order - I should include these in an extra README file, possibly > one that opens automatically when you mount the disk. > > * The build is from trunk, SVN revision 22913, as indicated in the > filename. The build script should allow me to provide arbitrary branch > builds, but I haven't tested that. > * The build is for Intel, and may possibly be 64-bit only - I've not > checked this. > * This was built on MacOS 10.7 to avoid the problems we've seen with > low-level pygobject crashes using XCode4 on 10.8. I don't yet have a > working 10.8.5 environment to see if this bug still exists, but I know > that a 10.7 build will at least not crash on startup! > * I'm not a registered Apple developer, so the binary isn't signed, > which means you have to right-click and select 'Open' to launch the app, > unless you've configured MacOS to ignore application signatures. > * I've done no real testing on this other than verifying that I can run > it and open an existing tree (with accompanying warnings about upgrading > the database, etc.) > * I've made some minor changes to the build to allow it to build; this > includes updating the bundler file, and fixing the resourcepath issue. I > know John's aware of the latter, not sure about the former since it only > matters when you're trying to build the finished application. In any > case, I can file a bug and offer a patch. > > I'd appreciate if any Mac users lurking on the list, developer or > otherwise, could give this a spin and let me know if it works for them. > DO NOT FEED THIS ANY DATA YOU CARE ABOUT WITHOUT BACKING UP FIRST. It's > a developer release, it will possibly contain bugs. > > Oh, and as noted, if my hosting costs suddenly skyrocket I'll be > removing this build. In any case, since the URL is based on the SVN > revision it has a limited lifetime :) Ronan, You can enable 32-bit builds with SDK 10.6 by calling setup_sdk(10.6, 10.6, [i386]) from your .jhbuildrc-custom. That will allow a somewhat broader audience to use the builds. Regards, John Ralls |
From: Ronan W. <wa...@gm...> - 2013-09-22 14:22:10
|
Hmm, seems there's more to it than that. It looks like any attempt to build for i386 (I tried setting a few different target/sdk combinations) results in a failure to locate libiconv during the build. Telling jhbuild to skip libiconv during bootstrap doesn't fix this; I'm guessing maybe telling jhbuild to skip libiconv in all circumstances may cause different problems, but I'll have another look at this once the current "native" build finishes. On a similar thread, I've tried building with Xcode 5, and jhbuild initially bombs out because it uses a nonexistent compiler; adding os.environ settings for CC and CXX to point to /usr/bin/cc and /usr/bin/c++ respectively gets the build going, but it throws a bunch of errors elsewhere that I've not yet looked into. I'll leave this to one side for the moment since I have a working build environment to play with on the 10.7 machine. Cheers, Waider. On 20 Sep 2013, at 14:41, John Ralls <jr...@ce...> wrote: > > On Sep 20, 2013, at 3:34 AM, Ronan Waide <wa...@gm...> wrote: > >> On 09/20/2013 10:39 AM, Vassilii Khachaturov wrote: >>> On 20.09.2013 12:29, Ronan Waide wrote: >>>> >>>> I can put the nightly Mac builds on my own webserver on a trial basis >>>> to see what sort of cost it incurs. I'm using Amazon Web Services, so >>>> if it turns out to be too expensive I'll figure out some way of >>>> restricting it. We could probably drop nightly builds into a >>>> directory on sourceforge, mind you. >>>> >>> Sounds great, thanks for willing to try it out! >>> v >> >> http://www.waider.ie/gramps/Gramps-Intel-trunk-r22913.dmg >> >> As this is the first one of these I've put together, a couple of notes >> are in order - I should include these in an extra README file, possibly >> one that opens automatically when you mount the disk. >> >> * The build is from trunk, SVN revision 22913, as indicated in the >> filename. The build script should allow me to provide arbitrary branch >> builds, but I haven't tested that. >> * The build is for Intel, and may possibly be 64-bit only - I've not >> checked this. >> * This was built on MacOS 10.7 to avoid the problems we've seen with >> low-level pygobject crashes using XCode4 on 10.8. I don't yet have a >> working 10.8.5 environment to see if this bug still exists, but I know >> that a 10.7 build will at least not crash on startup! >> * I'm not a registered Apple developer, so the binary isn't signed, >> which means you have to right-click and select 'Open' to launch the app, >> unless you've configured MacOS to ignore application signatures. >> * I've done no real testing on this other than verifying that I can run >> it and open an existing tree (with accompanying warnings about upgrading >> the database, etc.) >> * I've made some minor changes to the build to allow it to build; this >> includes updating the bundler file, and fixing the resourcepath issue. I >> know John's aware of the latter, not sure about the former since it only >> matters when you're trying to build the finished application. In any >> case, I can file a bug and offer a patch. >> >> I'd appreciate if any Mac users lurking on the list, developer or >> otherwise, could give this a spin and let me know if it works for them. >> DO NOT FEED THIS ANY DATA YOU CARE ABOUT WITHOUT BACKING UP FIRST. It's >> a developer release, it will possibly contain bugs. >> >> Oh, and as noted, if my hosting costs suddenly skyrocket I'll be >> removing this build. In any case, since the URL is based on the SVN >> revision it has a limited lifetime :) > > Ronan, > > You can enable 32-bit builds with SDK 10.6 by calling > setup_sdk(10.6, 10.6, [i386]) > from your .jhbuildrc-custom. That will allow a somewhat broader audience to use the builds. > > Regards, > John Ralls > -- wa...@gm... / It's about as impersonal as you can get. |
From: John R. <jr...@ce...> - 2013-09-22 15:43:50
|
On Sep 22, 2013, at 7:21 AM, Ronan Waide <wa...@gm...> wrote: > Hmm, seems there's more to it than that. It looks like any attempt to build for i386 (I tried setting a few different target/sdk combinations) results in a failure to locate libiconv during the build. Telling jhbuild to skip libiconv during bootstrap doesn't fix this; I'm guessing maybe telling jhbuild to skip libiconv in all circumstances may cause different problems, but I'll have another look at this once the current "native" build finishes. The i386 image in /usr/lib/libiconv.dylib is fine; it's the x86_64 one that's missing symbols. But we fixed glib to not notice a long time ago, and libiconv hasn't been in the modulesets since--so `skip libiconv` is a no-op. Since libiconv is definitely in all of the SDKs up through 10.8, it seems likely that something's misconfigured. What does `xcode-select -print-path` emit? > On a similar thread, I've tried building with Xcode 5, and jhbuild initially bombs out because it uses a nonexistent compiler; adding os.environ settings for CC and CXX to point to /usr/bin/cc and /usr/bin/c++ respectively gets the build going, but it throws a bunch of errors elsewhere that I've not yet looked into. I'll leave this to one side for the moment since I have a working build environment to play with on the 10.7 machine. I added the necessary patches for Xcode5 when the 10.9 dev preview came out, but I hadn't pushed them because it was subject to Apple's NDA. Thanks for reminding me that it's now released. I'll push them today. Regards, John Ralls |
From: Ronan W. <wa...@gm...> - 2013-09-22 16:31:32
|
On 22 Sep 2013, at 16:43, John Ralls <jr...@ce...> wrote: > > Since libiconv is definitely in all of the SDKs up through 10.8, it seems likely that something's misconfigured. > > What does `xcode-select -print-path` emit? > /Developer The specific error is when building xz: it can't find /usr/lib/libiconv.la. This is using a stock jhbuild with only your suggested setup_sdk in jhbuildrc-custom. > I added the necessary patches for Xcode5 when the 10.9 dev preview came out, but I hadn't pushed them because it was subject to Apple's NDA. Thanks for reminding me that it's now released. I'll push them today. Cool, will rerun this build. While I'm all for backward compatibility I'd like to have a build targeted at my working platform as well. Cheers, Waider. -- wa...@gm... / It's about as impersonal as you can get. |
From: John R. <jr...@ce...> - 2013-09-22 17:04:32
|
On Sep 22, 2013, at 9:31 AM, Ronan Waide <wa...@gm...> wrote: > > On 22 Sep 2013, at 16:43, John Ralls <jr...@ce...> wrote: >> >> Since libiconv is definitely in all of the SDKs up through 10.8, it seems likely that something's misconfigured. >> >> What does `xcode-select -print-path` emit? >> > > /Developer Really? What version of Xcode are you using? Does /Developer exist and contain SDKs? > > The specific error is when building xz: it can't find /usr/lib/libiconv.la. > > This is using a stock jhbuild with only your suggested setup_sdk in jhbuildrc-custom. > >> I added the necessary patches for Xcode5 when the 10.9 dev preview came out, but I hadn't pushed them because it was subject to Apple's NDA. Thanks for reminding me that it's now released. I'll push them today. > > > Cool, will rerun this build. While I'm all for backward compatibility I'd like to have a build targeted at my working platform as well. Pushed, but the current release of gtk-mac-integration doesn't build with Xcode5, only git master does. There are a couple of things I want to fix up, but I'll do a new release in a few days. Regards, John Ralls |
From: Ronan W. <wa...@gm...> - 2013-09-22 17:14:55
|
On 22 Sep 2013, at 18:04, John Ralls <jr...@ce...> wrote: > > On Sep 22, 2013, at 9:31 AM, Ronan Waide <wa...@gm...> wrote: > >> >> On 22 Sep 2013, at 16:43, John Ralls <jr...@ce...> wrote: >>> >>> Since libiconv is definitely in all of the SDKs up through 10.8, it seems likely that something's misconfigured. >>> >>> What does `xcode-select -print-path` emit? >>> >> >> /Developer > > Really? What version of Xcode are you using? Does /Developer exist and contain SDKs? > twong:~ localwaider$ xcodebuild -version Xcode 4.3.1 Build version 4E1019 twong:~ localwaider$ ls /Developer/Platforms/MacOSX.platform/Developer/SDKs MacOSX10.6.sdk MacOSX10.7.sdk Note, this is able to build a native build just fine - it's only if I specify i386 in setup_sdk that it breaks. Configure successfully determines that it's to use -liconv when linking, but somehow libtool seems to decide that that's best accomplished by looking for the .la file.: ----------- /bin/sh ../../libtool --tag=CC --mode=link /Developer/usr/bin/llvm-gcc-4.2 -std=gnu99 -D_THREAD_SAFE -pthread -fvisibility=hidden -Wall -Wextra -Wformat=2 -Winit-self -Wmissing-include-dirs -Wstrict-aliasing -Wfloat-equal -Wundef -Wshadow -Wpointer-arith -Wbad-function-cast -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes -Wmissing-declarations -Wmissing-noreturn -Wredundant-decls -arch i386 -I/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk/usr/include -isysroot /Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.6 -L/Users/localwaider/gtk/inst/lib -L/Users/localwaider/gtk/inst/lib -arch i386 -L/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk/usr/lib -isysroot /Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.6 -Wl,-headerpad_max_install_names -o lzmadec lzmadec-xzdec.o lzmadec-tuklib_progname.o lzmadec-tuklib_exit.o ../../src/liblzma/liblzma.la -lintl -Wl,-framework -Wl,CoreFoundation libtool: link: cannot find the library `/usr/lib/libiconv.la' or unhandled argument `/usr/lib/libiconv.la' make[3]: *** [xzdec] Error 1 ---------- >>> I added the necessary patches for Xcode5 when the 10.9 dev preview came out, but I hadn't pushed them because it was subject to Apple's NDA. Thanks for reminding me that it's now released. I'll push them today. >> >> >> Cool, will rerun this build. While I'm all for backward compatibility I'd like to have a build targeted at my working platform as well. > > Pushed, but the current release of gtk-mac-integration doesn't build with Xcode5, only git master does. There are a couple of things I want to fix up, but I'll do a new release in a few days. > I'll keep an eye out for that. Cheers, Waider. -- wa...@gm... / It's about as impersonal as you can get. |
From: John R. <jr...@ce...> - 2013-09-22 22:41:56
|
On Sep 22, 2013, at 10:14 AM, Ronan Waide <wa...@gm...> wrote: > > On 22 Sep 2013, at 18:04, John Ralls <jr...@ce...> wrote: > >> >> On Sep 22, 2013, at 9:31 AM, Ronan Waide <wa...@gm...> wrote: >> >>> >>> On 22 Sep 2013, at 16:43, John Ralls <jr...@ce...> wrote: >>>> >>>> Since libiconv is definitely in all of the SDKs up through 10.8, it seems likely that something's misconfigured. >>>> >>>> What does `xcode-select -print-path` emit? >>>> >>> >>> /Developer >> >> Really? What version of Xcode are you using? Does /Developer exist and contain SDKs? >> > > twong:~ localwaider$ xcodebuild -version > Xcode 4.3.1 > Build version 4E1019 > > twong:~ localwaider$ ls /Developer/Platforms/MacOSX.platform/Developer/SDKs > MacOSX10.6.sdk MacOSX10.7.sdk > > Note, this is able to build a native build just fine - it's only if I specify i386 in setup_sdk that it breaks. Configure successfully determines that it's to use -liconv when linking, but somehow libtool seems to decide that that's best accomplished by looking for the .la file.: > > ----------- > /bin/sh ../../libtool --tag=CC --mode=link /Developer/usr/bin/llvm-gcc-4.2 -std=gnu99 -D_THREAD_SAFE -pthread -fvisibility=hidden -Wall -Wextra -Wformat=2 -Winit-self -Wmissing-include-dirs -Wstrict-aliasing -Wfloat-equal -Wundef -Wshadow -Wpointer-arith -Wbad-function-cast -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes -Wmissing-declarations -Wmissing-noreturn -Wredundant-decls -arch i386 -I/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk/usr/include -isysroot /Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.6 -L/Users/localwaider/gtk/inst/lib -L/Users/localwaider/gtk/inst/lib -arch i386 -L/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk/usr/lib -isysroot /Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.6 -Wl,-headerpad_max_install_names -o lzmadec lzmadec-xzdec.o lzmadec-tuklib_progname.o lzmadec-tuklib_exit.o ../../src/liblzma/liblzma.la -lintl -Wl,-framework -Wl,CoreFoundation > libtool: link: cannot find the library `/usr/lib/libiconv.la' or unhandled argument `/usr/lib/libiconv.la' > make[3]: *** [xzdec] Error 1 > ---------- > /Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk/usr/include That's a weird setup, but OK. But lzmadec shouldn't be pulling in libintl (which is what's referencing libiconv). Libintl is provided by gettext-tools, which builds *after* xz. For comparison, here's what that same command looks like from a build I just ran (with Xcode5 on 10.8, which provides only a 10.8 SDK): /bin/sh ../../libtool --tag=CC --mode=link gcc -D_THREAD_SAFE -pthread -fvisibility=hidden -Wall -Wextra -Wformat=2 -Winit-self -Wmissing-include-dirs -Wstrict-aliasing -Wfloat-equal -Wundef -Wshadow -Wpointer-arith -Wbad-function-cast -Wwrite-strings -Wlogical-op -Waggregate-return -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes -Wmissing-declarations -Wmissing-noreturn -Wredundant-decls -arch i386 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/include -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk -mmacosx-version-min=10.8 -L/Users/john/gtk/inst/lib -L/Users/john/gtk/inst/lib -arch i386 -L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk -mmacosx-version-min=10.8 -Wl,-headerpad_max_install_names -o lzmadec lzmadec-xzdec.o lzmadec-tuklib_progname.o lzmadec-tuklib_exit.o ../../src/liblzma/liblzma.la Regards, John Ralls |
From: Ronan W. <wa...@gm...> - 2013-09-23 10:55:21
|
On 22 Sep 2013, at 23:41, John Ralls <jr...@ce...> wrote: > > On Sep 22, 2013, at 10:14 AM, Ronan Waide <wa...@gm...> wrote: > >> >> On 22 Sep 2013, at 18:04, John Ralls <jr...@ce...> wrote: >> >>> >>> On Sep 22, 2013, at 9:31 AM, Ronan Waide <wa...@gm...> wrote: >>> >>>> >>>> On 22 Sep 2013, at 16:43, John Ralls <jr...@ce...> wrote: >>>>> >>>>> Since libiconv is definitely in all of the SDKs up through 10.8, it seems likely that something's misconfigured. >>>>> >>>>> What does `xcode-select -print-path` emit? >>>>> >>>> >>>> /Developer >>> >>> Really? What version of Xcode are you using? Does /Developer exist and contain SDKs? >>> >> >> twong:~ localwaider$ xcodebuild -version >> Xcode 4.3.1 >> Build version 4E1019 >> >> twong:~ localwaider$ ls /Developer/Platforms/MacOSX.platform/Developer/SDKs >> MacOSX10.6.sdk MacOSX10.7.sdk >> >> Note, this is able to build a native build just fine - it's only if I specify i386 in setup_sdk that it breaks. Configure successfully determines that it's to use -liconv when linking, but somehow libtool seems to decide that that's best accomplished by looking for the .la file.: >> >> ----------- >> /bin/sh ../../libtool --tag=CC --mode=link /Developer/usr/bin/llvm-gcc-4.2 -std=gnu99 -D_THREAD_SAFE -pthread -fvisibility=hidden -Wall -Wextra -Wformat=2 -Winit-self -Wmissing-include-dirs -Wstrict-aliasing -Wfloat-equal -Wundef -Wshadow -Wpointer-arith -Wbad-function-cast -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes -Wmissing-declarations -Wmissing-noreturn -Wredundant-decls -arch i386 -I/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk/usr/include -isysroot /Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.6 -L/Users/localwaider/gtk/inst/lib -L/Users/localwaider/gtk/inst/lib -arch i386 -L/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk/usr/lib -isysroot /Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.6 -Wl,-headerpad_max_install_names -o lzmadec lzmadec-xzdec.o lzmadec-tuklib_progname.o lzmadec-tuklib_exit.o ../../src/liblzma/liblzma.la -lintl -Wl,-framework -Wl,CoreFoundation >> libtool: link: cannot find the library `/usr/lib/libiconv.la' or unhandled argument `/usr/lib/libiconv.la' >> make[3]: *** [xzdec] Error 1 >> ---------- > >> /Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk/usr/include > > That's a weird setup, but OK. > Mmm. I don't recall doing anything special for it to get that way. This is an old-ish MacBook that's been upgraded from some past OSX version as far as it'll go, so possibly some previous install of Xcode on some previous version of OSX resulted in this. I've been thinking about doing a wipe and reinstall; maybe it's finally time :) > But lzmadec shouldn't be pulling in libintl (which is what's referencing libiconv). Libintl is provided by gettext-tools, > which builds *after* xz. > > For comparison, here's what that same command looks like from a build I just ran (with Xcode5 on 10.8, which provides only a 10.8 SDK): > /bin/sh ../../libtool --tag=CC --mode=link gcc -D_THREAD_SAFE -pthread -fvisibility=hidden -Wall -Wextra -Wformat=2 -Winit-self -Wmissing-include-dirs -Wstrict-aliasing -Wfloat-equal -Wundef -Wshadow -Wpointer-arith -Wbad-function-cast -Wwrite-strings -Wlogical-op -Waggregate-return -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes -Wmissing-declarations -Wmissing-noreturn -Wredundant-decls -arch i386 -I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/include -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk -mmacosx-version-min=10.8 -L/Users/john/gtk/inst/lib -L/Users/john/gtk/inst/lib -arch i386 -L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk -mmacosx-version-min=10.8 -Wl,-headerpad_max_install_names -o lzmadec lzmadec-xzdec.o lzmadec-tuklib_progname.o lzmadec-tuklib_exit.o ../../src/liblzma/liblzma.la Ok, I may get some time to poke at this further during the week. cheers, Waider. -- wa...@gm... / It's about as impersonal as you can get. |
From: John R. <jr...@ce...> - 2013-09-23 14:00:15
|
On Sep 23, 2013, at 3:55 AM, Ronan Waide <wa...@gm...> wrote: > > On 22 Sep 2013, at 23:41, John Ralls <jr...@ce...> wrote: > >> >>> /Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk/usr/include >> >> That's a weird setup, but OK. >> > > Mmm. I don't recall doing anything special for it to get that way. This is an old-ish MacBook that's been upgraded from some past OSX version as far as it'll go, so possibly some previous install of Xcode on some previous version of OSX resulted in this. I've been thinking about doing a wipe and reinstall; maybe it's finally time :) Xcode 4.3 was the first App Store Xcode. Normally it lives in /Applications/Xcode.app with all of its pieces inside the applications bundle. This facilitates having multiple Xcode installations, and xcode-select is provided to switch among them. But I switched to 10.8 before 4.3 was released, so maybe they made it install differently on 10.7. Maybe when 10.9 gets released in the next month or three you can just do an archive and install when you upgrade. ;-) Regards, John Ralls |
From: Ronan W. <wa...@gm...> - 2013-10-07 06:45:02
|
> On 23 Sep 2013, at 15:00, John Ralls <jr...@ce...> wrote: > > >> On Sep 23, 2013, at 3:55 AM, Ronan Waide <wa...@gm...> wrote: >> >> >>> On 22 Sep 2013, at 23:41, John Ralls <jr...@ce...> wrote: >>> >>> >>>> /Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.6.sdk/usr/include >>> >>> That's a weird setup, but OK. >>> >> >> Mmm. I don't recall doing anything special for it to get that way. This is an old-ish MacBook that's been upgraded from some past OSX version as far as it'll go, so possibly some previous install of Xcode on some previous version of OSX resulted in this. I've been thinking about doing a wipe and reinstall; maybe it's finally time :) > > Xcode 4.3 was the first App Store Xcode. Normally it lives in /Applications/Xcode.app with all of its pieces inside the applications bundle. This facilitates having multiple Xcode installations, and xcode-select is provided to switch among them. But I switched to 10.8 before 4.3 was released, so maybe they made it install differently on 10.7. > > Maybe when 10.9 gets released in the next month or three you can just do an archive and install when you upgrade. ;-) > > Regards, > John Ralls > I removed and reinstalled Xcode on the 10.7 machine this weekend. Installing a functional Xcode 3 is no longer possible as the installer greys out the actual tools (I guess I could crack open the .pkg and try installing things individually) so you just wind up with a /Developer stub directory with a handful of tools like Application Loader in it. XCode 4.3 is a simple drag-to-Applications-folder installation, after which I installed the command line tools from within Xcode. Results: - I still get the same library error that started this thread if I do a i386 build - the native build dies with the same g-ir-scanner failure I mentioned elsewhere. I guess the next step I'll be taking is scrubbing the 10.7 machine entirely, i.e. OS reinstall. Cheers, Waider -- Sent from my Internet |
From: Ronan W. <wa...@gm...> - 2013-10-07 20:03:25
|
On 7 Oct 2013, at 07:44, Ronan Waide <wa...@gm...> wrote: > - I still get the same library error that started this thread if I do a i386 build solved this. Turns out I had a /usr/local on the machine with some arbitrary rubbish in it. Moving that out of the way fixes the library problem, so I'm just left with (a) the g-ir-scanner issue and (b) the glib thing you mentioned in the other thread. cheers, Waider. -- wa...@gm... / It's about as impersonal as you can get. |
From: John R. <jr...@ce...> - 2013-10-07 20:12:59
|
On Oct 7, 2013, at 1:03 PM, Ronan Waide <wa...@gm...> wrote: > > On 7 Oct 2013, at 07:44, Ronan Waide <wa...@gm...> wrote: > >> - I still get the same library error that started this thread if I do a i386 build > > solved this. Turns out I had a /usr/local on the machine with some arbitrary rubbish in it. Moving that out of the way fixes the library problem, so I'm just left with (a) the g-ir-scanner issue and (b) the glib thing you mentioned in the other thread. The only active glib problem I'm aware of is charset.alias not getting installed. Have I forgotten something? Is the g-ir-scanner problem the assert in ast.py or the crash that's always happened when trying to build Gramps on 10.7/8? Regards, John Ralls |
From: Ronan W. <wa...@gm...> - 2013-10-07 20:20:49
|
On 7 Oct 2013, at 21:12, John Ralls <jr...@ce...> wrote: > The only active glib problem I'm aware of is charset.alias not getting installed. Have I forgotten something? > > Is the g-ir-scanner problem the assert in ast.py or the crash that's always happened when trying to build Gramps on 10.7/8? Yes and yes. As previously noted, if you replace the assert in ast.py with 'return None' it seems to work ok, but I'm curious about the underlying problem. cheers, Waider. -- wa...@gm... / It's about as impersonal as you can get. |
From: Ronan W. <wa...@gm...> - 2013-10-14 20:47:01
|
Right, finally! I managed to get a full 10.6, i386 build from SVN trunk. Since the SVN trunk revision doesn't appear to have changed, I'll be dropping the .dmg over the original one at http://www.waider.ie/gramps/Gramps-Intel-trunk-r22913.dmg I've run this in a clean environment, and imported a small .ged file, and clicked through all the sidebar items, so it seems to run on at least a cursory check. I did notice that I seem to be missing the sidebar icons in the file viewer (i.e. icons for Home, etc.) but aside from that everything looks ok and nothing crashed (yet). I would appreciate if anyone with time can pull a copy of this and kick the tyres a bit to see if there are bugs. I've put my "clean build" script at http://www.waider.ie/hacks/workshop/gramps/ in case anyone wants to replicate my build. John, FWIW I can't currently complete a build with Xcode 5 on 10.8.5, but since my last mishap (the /usr/local with conflicting files in it) I'm not 100% certain if it's the build or my environment, so I'm going to see if I can figure out what's busted before posting further details. Cheers, Waider. -- wa...@gm... / It's about as impersonal as you can get. |
From: Ronan W. <wa...@gm...> - 2013-10-15 07:05:50
|
On 14 Oct 2013, at 21:46, Ronan Waide <wa...@gm...> wrote: > John, FWIW I can't currently complete a build with Xcode 5 on 10.8.5, but since my last mishap (the /usr/local with conflicting files in it) I'm not 100% certain if it's the build or my environment, so I'm going to see if I can figure out what's busted before posting further details. Ok, reproduced this in a clean environment with 10.8.5 / Xcode 5 (so I know it's not a stray copy of libgcrypt sneaking in). I'm getting a whole list of duplicate symbols between mpi/ec.c and other files in the mpi directory, but it was running overnight so I've not had a chance to dig in further yet. If this rings a bell, let me know, otherwise I'll see if I can track down the problem this evening. At first glance I'd guess either a missing ifdef or an include file defining things that gets pulled into two source files when it should only go into one. Cheers, Waider. -- wa...@gm... / It's about as impersonal as you can get. |
From: Ronan W. <wa...@gm...> - 2013-10-15 12:56:17
|
On 10/15/2013 08:05 AM, Ronan Waide wrote: > On 14 Oct 2013, at 21:46, Ronan Waide <wa...@gm...> wrote: > >> John, FWIW I can't currently complete a build with Xcode 5 on 10.8.5, but since my last mishap (the /usr/local with conflicting files in it) I'm not 100% certain if it's the build or my environment, so I'm going to see if I can figure out what's busted before posting further details. > Ok, reproduced this in a clean environment with 10.8.5 / Xcode 5 (so I know it's not a stray copy of libgcrypt sneaking in). I'm getting a whole list of duplicate symbols between mpi/ec.c and other files in the mpi directory, but it was running overnight so I've not had a chance to dig in further yet. If this rings a bell, let me know, otherwise I'll see if I can track down the problem this evening. At first glance I'd guess either a missing ifdef or an include file defining things that gets pulled into two source files when it should only go into one. > > Cheers, > Waider. This is looking like a problem with the extern __inline__ declarations in mpi-internal.h - the functions declared thus seem to wind up being exposed as public symbols: Xcode4 (working): bash-3.2$ nm mpi/.libs/ec.o |grep _cmp U __gcry_mpi_cmp U __gcry_mpi_cmp_ui Xcode5 (broken): bash-3.2$ nm mpi/.libs/ec.o |grep _cmp U __gcry_mpi_cmp U __gcry_mpi_cmp_ui 00000000000003f0 T __gcry_mpih_cmp 0000000000001bc8 S __gcry_mpih_cmp.eh Cheers, Waider -- wa...@gm... / It's about as impersonal as you can get. |
From: John R. <jr...@ce...> - 2013-10-15 16:05:23
|
On Oct 15, 2013, at 5:56 AM, Ronan Waide <wa...@gm...> wrote: > On 10/15/2013 08:05 AM, Ronan Waide wrote: >> On 14 Oct 2013, at 21:46, Ronan Waide <wa...@gm...> wrote: >> >>> John, FWIW I can't currently complete a build with Xcode 5 on 10.8.5, but since my last mishap (the /usr/local with conflicting files in it) I'm not 100% certain if it's the build or my environment, so I'm going to see if I can figure out what's busted before posting further details. >> Ok, reproduced this in a clean environment with 10.8.5 / Xcode 5 (so I know it's not a stray copy of libgcrypt sneaking in). I'm getting a whole list of duplicate symbols between mpi/ec.c and other files in the mpi directory, but it was running overnight so I've not had a chance to dig in further yet. If this rings a bell, let me know, otherwise I'll see if I can track down the problem this evening. At first glance I'd guess either a missing ifdef or an include file defining things that gets pulled into two source files when it should only go into one. >> >> Cheers, >> Waider. > This is looking like a problem with the extern __inline__ declarations in mpi-internal.h - the functions declared thus seem to wind up being exposed as public symbols: > > Xcode4 (working): > bash-3.2$ nm mpi/.libs/ec.o |grep _cmp > U __gcry_mpi_cmp > U __gcry_mpi_cmp_ui > > Xcode5 (broken): > bash-3.2$ nm mpi/.libs/ec.o |grep _cmp > U __gcry_mpi_cmp > U __gcry_mpi_cmp_ui > 00000000000003f0 T __gcry_mpih_cmp > 0000000000001bc8 S __gcry_mpih_cmp.eh No, but I hadn't yet gotten around to trying to build Gramps with Xcode5, so I started this morning. After dealing with a berkeley-db config issue, I got hung up with Python-2.7.4; it keeps picking up incompatible modules from /System/Frameworks and crashing. So you're ahead of me on this one. Regards, John Ralls |
From: Ronan W. <wa...@gm...> - 2013-10-15 16:12:24
|
On 10/15/2013 05:05 PM, John Ralls wrote: > On Oct 15, 2013, at 5:56 AM, Ronan Waide <wa...@gm...> wrote: > >> On 10/15/2013 08:05 AM, Ronan Waide wrote: >>> On 14 Oct 2013, at 21:46, Ronan Waide <wa...@gm...> wrote: >>> >>>> John, FWIW I can't currently complete a build with Xcode 5 on 10.8.5, but since my last mishap (the /usr/local with conflicting files in it) I'm not 100% certain if it's the build or my environment, so I'm going to see if I can figure out what's busted before posting further details. >>> Ok, reproduced this in a clean environment with 10.8.5 / Xcode 5 (so I know it's not a stray copy of libgcrypt sneaking in). I'm getting a whole list of duplicate symbols between mpi/ec.c and other files in the mpi directory, but it was running overnight so I've not had a chance to dig in further yet. If this rings a bell, let me know, otherwise I'll see if I can track down the problem this evening. At first glance I'd guess either a missing ifdef or an include file defining things that gets pulled into two source files when it should only go into one. >>> >>> Cheers, >>> Waider. >> This is looking like a problem with the extern __inline__ declarations in mpi-internal.h - the functions declared thus seem to wind up being exposed as public symbols: >> >> Xcode4 (working): >> bash-3.2$ nm mpi/.libs/ec.o |grep _cmp >> U __gcry_mpi_cmp >> U __gcry_mpi_cmp_ui >> >> Xcode5 (broken): >> bash-3.2$ nm mpi/.libs/ec.o |grep _cmp >> U __gcry_mpi_cmp >> U __gcry_mpi_cmp_ui >> 00000000000003f0 T __gcry_mpih_cmp >> 0000000000001bc8 S __gcry_mpih_cmp.eh > No, but I hadn't yet gotten around to trying to build Gramps with Xcode5, so I started this morning. After dealing with a berkeley-db config issue, I got hung up with Python-2.7.4; it keeps picking up incompatible modules from /System/Frameworks and crashing. > > So you're ahead of me on this one. > > Regards, > John Ralls > It looks like putting this in jhbuildrc-custom fixes it: os.environ["CFLAGS"] = "-fgnu89-inline" but that seems like a pretty heavy-handed "fix". I 'fixed' python in my build script by explicitly building it before I tackle gramps. The alternative is to use the MacOS versioner to set python's default version explicitly to 2.6 so that the 2.7.4 build doesn't fight with it. Cheers, Waider -- wa...@gm... / It's about as impersonal as you can get. |
From: John R. <jr...@ce...> - 2013-10-15 21:38:24
|
On Oct 15, 2013, at 9:12 AM, Ronan Waide <wa...@gm...> wrote: > On 10/15/2013 05:05 PM, John Ralls wrote: >> On Oct 15, 2013, at 5:56 AM, Ronan Waide <wa...@gm...> wrote: >> >>> On 10/15/2013 08:05 AM, Ronan Waide wrote: >>>> On 14 Oct 2013, at 21:46, Ronan Waide <wa...@gm...> wrote: >>>> >>>>> John, FWIW I can't currently complete a build with Xcode 5 on 10.8.5, but since my last mishap (the /usr/local with conflicting files in it) I'm not 100% certain if it's the build or my environment, so I'm going to see if I can figure out what's busted before posting further details. >>>> Ok, reproduced this in a clean environment with 10.8.5 / Xcode 5 (so I know it's not a stray copy of libgcrypt sneaking in). I'm getting a whole list of duplicate symbols between mpi/ec.c and other files in the mpi directory, but it was running overnight so I've not had a chance to dig in further yet. If this rings a bell, let me know, otherwise I'll see if I can track down the problem this evening. At first glance I'd guess either a missing ifdef or an include file defining things that gets pulled into two source files when it should only go into one. >>>> >>>> Cheers, >>>> Waider. >>> This is looking like a problem with the extern __inline__ declarations in mpi-internal.h - the functions declared thus seem to wind up being exposed as public symbols: >>> >>> Xcode4 (working): >>> bash-3.2$ nm mpi/.libs/ec.o |grep _cmp >>> U __gcry_mpi_cmp >>> U __gcry_mpi_cmp_ui >>> >>> Xcode5 (broken): >>> bash-3.2$ nm mpi/.libs/ec.o |grep _cmp >>> U __gcry_mpi_cmp >>> U __gcry_mpi_cmp_ui >>> 00000000000003f0 T __gcry_mpih_cmp >>> 0000000000001bc8 S __gcry_mpih_cmp.eh >> No, but I hadn't yet gotten around to trying to build Gramps with Xcode5, so I started this morning. After dealing with a berkeley-db config issue, I got hung up with Python-2.7.4; it keeps picking up incompatible modules from /System/Frameworks and crashing. >> >> So you're ahead of me on this one. >> >> Regards, >> John Ralls >> > It looks like putting this in jhbuildrc-custom fixes it: > > os.environ["CFLAGS"] = "-fgnu89-inline" > > but that seems like a pretty heavy-handed "fix". > > I 'fixed' python in my build script by explicitly building it before I tackle gramps. The alternative is to use the MacOS versioner to set python's default version explicitly to 2.6 so that the 2.7.4 build doesn't fight with it. > Strange. I don't see that problem at all, though there were a lot of complaints from clang that needed -fheinous-gnu-extensions to get past, and assembler errors in ciphers/rijndael.c. I found a patch for the latter, only on master, and have adjusted it for libgcrypt-1.5.3 and added it, along with some other changes to get through other packages. BTW, you can adjust the CFLAGS for a single package like this: autogenargs.append('libgcrypt', 'CFLAGS=$CFLAGS -fheinous-gnu-extensions"') Regards, John Ralls |
From: John R. <jr...@ce...> - 2013-10-16 15:29:32
|
On Oct 15, 2013, at 2:38 PM, John Ralls <jr...@ce...> wrote: > > On Oct 15, 2013, at 9:12 AM, Ronan Waide <wa...@gm...> wrote: > >> It looks like putting this in jhbuildrc-custom fixes it: >> >> os.environ["CFLAGS"] = "-fgnu89-inline" >> >> but that seems like a pretty heavy-handed "fix". >> >> I 'fixed' python in my build script by explicitly building it before I tackle gramps. The alternative is to use the MacOS versioner to set python's default version explicitly to 2.6 so that the 2.7.4 build doesn't fight with it. >> > > Strange. I don't see that problem at all, though there were a lot of complaints > from clang that needed -fheinous-gnu-extensions to get past, and assembler errors > in ciphers/rijndael.c. I found a patch for the latter, only on master, and have > adjusted it for libgcrypt-1.5.3 and added it, along with some other changes to get through other packages. > > BTW, you can adjust the CFLAGS for a single package like this: > autogenargs.append('libgcrypt', 'CFLAGS=$CFLAGS -fheinous-gnu-extensions"') I finally got Gramps to build all the way through (there's a hand adjustment needed for pygobject, to touch ChangeLog, that I need to patch). It still crashes: A timeout dispatch is getting invoked with a bad callback. Regards, John Ralls |