Traceback (most recent call last):File "/Users/gtk-build/gtk/inst/bin/gtkdoc-rebase", line 28, in <module>from gtkdoc import common, config, rebaseFile "/Users/gtk-build/gtk/inst/share/gtk-doc/python/gtkdoc/common.py", line 31, in <module>import sixImportError: No module named six
Jeff,You should manually override libz. The easiest way would be to add it to your skip list so that it isn’t built.You can file a bug against Pango, the bug tracker is https://bugzilla.gnome.orguntil Pango gets migrated to https://gitlab.gnome.org ( supposedly sometime this month). It will get attention faster if you can provide a patch. Behdad isn’t terribly familiar with the details of the MacOS API. Regards,John RallsOn May 9, 2018, at 9:34 AM, Jeffrey Sheen <jeffrey.sheen00@alumni.imperial.ac.uk > wrote:Hi John,I've had success building i386 and x86_64 flavours of the pango/cairo dylibs and using lipo to create universal binaries.However, uploading to the Mac App Store, I encountered the following two issues:
- By default, GTK+ is building its own version of libzip and linking other libraries to it. This is not allowed by Apple, who insist on their distributed library being used.
- There is a call to `CTFontCopyDefaultCascadeList' in `pangocoretext-fontmap.c', which is not allowed by Apple, as it is not a "public" API function.
Is there an easy way to have GTK+ OSX build and link against the system's libzip, or shall I manually override that?As we only use FontConfig, not Core Text, do you know if there is a way of disabling all other font managers in the build config of the stack?Cheers,Jeff.On 31 March 2018 at 00:50, Jeffrey Sheen <jeffrey.sheen00@alumni.imperial.ac.uk > wrote:You're too quick for me John!Nice one.On Sat, 31 Mar 2018, 00:48 John Ralls, <jralls ceridwen us> wrote:Yes, you need to build python for i386 because the one Apple provides is x86_64 only.
The reason adding libxml2 and python didn't do anything for you is because you've already build libxml2 (it's included in meta-gtk-osx-bootstrap) and you need to rebuild it with python:
jhbuild build -f --clean libxml2 python
Regards,
John Ralls
> On Mar 30, 2018, at 4:37 PM, Jeffrey Sheen <jeffrey.sheen00@alumni.imperial.ac.uk > wrote:
>
> Great tip, thanks John. It did not occur to me that some of the `bootstrap' modules were optional for subsequent builds.
>
> This command worked for the `x86_64' build:
>
> jhbuild build meta-gtk-osx-bootstrap meta-gtk-osx-freetype pango
>
> However, I am encountering an error when building `i386':
>
> checking for python script directory... ${prefix}/lib/python2.7/site-packages
> checking for python extension module directory... ${exec_prefix}/lib/python2.7/site-packages
> checking for python module libxml2... not found
> configure: error: Python module libxml2 is needed to run this package
> *** Error during phase configure of itstool: ########## Error running ./configure --prefix /Users/gtk-build/gtk/inst *** [8/25]
>
> I tried adding modules `libxml2' and `python' to the list explicitly, but with the same result.
>
> N.B. In the `~/gtk/inst/lib/python2.7/site-packages/' directory for the `x86_64' build, there are multiple `libxml' and `libxslt' library/module files. At the point of failure in the `i386' build, the `libxml' files are present in the same location, but the `libxslt' files are not.
>
> I'm not sure why the error is being generated, so I am going to debug `~/gtk/source/itstool-2.0.2/configure'. The error message is being generated at line 2426.
>
> On 29 March 2018 at 02:01, John Ralls <jralls ceridwen us> wrote:
>
>
>> On Mar 28, 2018, at 8:38 AM, Jeffrey Sheen <jeffrey.sheen00@alumni.imperial.ac.uk > wrote:
>>
>> N.B. Using a Sierra 10.12.6 environment with Xcode 9.2 and the `~/.jhbuildrc-custom' parameters:
>>
>> setup_sdk(target='10.6')
>> or
>> setup_sdk(target='10.7')
>>
>> This causes `jhbuild bootstrap' to fail when bootstrapping `cmake 3.10.0':
>>
>> clang: warning: libstdc++ is deprecated; move to libc++ with a minimum deployment target of OS X 10.9 [-Wdeprecated]
>> cmake_bootstrap_24961_test.cxx:6:2: error: "Compiler is not in a mode aware of C++11."
>>
>> The approach I am taking now is to roll back to gtk-osx `Last-Lion', and create a custom local branch to fold in subsequent commits necessary to update pango/cairo/freetype versions.
>>
>> I may need to set up a custom environment to improve build compatibility.
>
> Unless you need cmake for some reason, why don’t you just add cmake to the skip list in .jhbuildrc-custom?
>
> Regards,
> John Ralls
>
>