Unless you have set up out-of-source builds by defining buildroot in .jhbuildrc-custom, *everything*. That would be `rm -rf ~/gtk` if you use the jhbuildrc defaults.If you set buildroot then you can just nuke it and prefix.If you’re going to try to build for 10.7 on a later version be sure you have a machine or VM running 10.7 that you can test on. Last I checked old MacOS versions were available from the downloads section of developer.apple.com if you’re a registered Developer (and I guess you must be if you’re using the App Store). I’ve found VMWare Fusion works quite well for the purpose.I’m curious about only needing Pango, Cairo, and Freetype. That implies that you’re creating a cairo surface inside of an NSView, which strikes me as a bit odd. Why not just go the rest of the way and do a fully native implementation?Regards,John RallsOn Mar 22, 2018, at 5:17 PM, Jeffrey Sheen <jeffrey.sheen00@alumni.imperial.ac.uk > wrote:Cheers John. Which directories should be nuked to execute `jhbuild bootstrap' clean?netmarketshare and statscounter data suggests that 10.6 installs constitute 1.48-1.78% of OS X users.That's not nothing, but is small enough that I'll target a 64-bit only release.I'll try to wrangle an environment that will build 10.7 compatible libs. I only need pango/cairo/freetype and their dependencies.On 22 Mar 2018 23:23, "John Ralls" <jralls ceridwen us> wrote:As for the app store: https://developer.apple.com/news/?id=12012017a . I guess they may continue to take 64/32 universals, but I've never tried building one. Intel/PPC universals were possible but excruciatingly painful.
Regards,
John Ralls
> On Mar 22, 2018, at 4:14 PM, John Ralls <jralls ceridwen us> wrote:
>
> Clean in this case means "empty", as in rm -r empty. If you don't want to keep the 64-bit build around you can just nuke it and start over. If you do, just set a new prefix in jhbuildrc-custom. It's python, you can easily program it to respond to environment variables. Start fresh with `jhbuild bootstrap`, then build.
>
> Regards,
> John Ralls
>
>
>> On Mar 22, 2018, at 3:50 PM, Jeffrey Sheen <jeffrey.sheen00@alumni.imperial.ac.uk > wrote:
>>
>> Thank you for your insight John. I appreciate you sharing Apple's 32-bit retirement roadmap.
>>
>> I'll now investigate migrating to a 64-bit binary as standard.
>>
>> I don't want to leave any of our users behind, but it's the platform holder banging the drum. I'll have to find out the timescale Apple are operating on for sunsetting 32-bit distribution on their App Store.
>>
>> As for a clean prefix, I called `jhbuild build --force'. Is there a more "scorched-earth" approach to starting from bootstrap?
>>
>> On 22 Mar 2018 19:04, "John Ralls" <jralls ceridwen us> wrote:
>> I guess I should reiterate that I stopped supporting MacOS earlier than MacOS X 10.9 a year ago, and that will soon change to 10.10 -- and that means that building for i386 is not really supported either. Add to that that Apple announced at WWDC next year that 10.14 will support i386 in some sort of reduced-performance mode and that 10.15 won't have any i386 support at all. 10.13.3+ already puts up a snotty message about 32-bit binaries.
>>
>> BTW I've gotten bug reports with the stub libraries on older MacOS versions so I've reverted to building on a VM of the oldest version of MacOS that I intend users to run on, generally meaning 10.9.
>>
>> Regards,
>> John Ralls
>>
>>
>>> On Mar 22, 2018, at 11:55 AM, John Ralls <jralls ceridwen us> wrote:
>>>
>>> What version of OSX? Did you start from bootstrap in a completely clean prefix?
>>>
>>> Regards,
>>> John Ralls
>>>
>>>> On Mar 22, 2018, at 11:25 AM, Jeffrey Sheen <jeffrey.sheen00@alumni.imperial.ac.uk > wrote:
>>>>
>>>> Hi John,
>>>>
>>>> Thank you for your help so far. I managed to build a version of gtk including freetype for the native architecture of my machine (x86_64).
>>>>
>>>> However, I need an i386 build for the distribution, and have encountered linker errors after altering `.jhbuildrc-custom' to:
>>>>
>>>> setup_sdk(target='10.7', sdk_version=None, architectures=['i386'])
>>>>
>>>> The errors are all of the form:
>>>>
>>>> Undefined symbols for architecture i386:
>>>> "_main", referenced from:
>>>> start in crt1.10.6.o
>>>> ld: symbol(s) not found for architecture i386
>>>> clang: error: linker command failed with exit code 1 (use -v to see invocation)
>>>>
>>>> Having read the docs, I believe I have the `setup_sdk' parameterisation correct, but perhaps you can spot my mistake?
>>>>
>>>> On 16 March 2018 at 21:20, Jeffrey Sheen <jeffrey.sheen00@alumni.imperial.ac.uk > wrote:
>>>> Thank you John. I'll try altering the build parameters as you've suggested.
>>>>
>>>> I take your point about native font management.
>>>>
>>>> The issue is that we've found Win32 native font selection to be erratic, changing fonts between Pango layout objects, despite a static font description. We now bundle fonts with the distributable to assure consistency.
>>>>
>>>> If there is a native way to stream in packaged fonts other than fontconfig, then we will try that.
>>>>
>>>>
>>>> On 16 Mar 2018 20:52, "John Ralls" <jralls ceridwen us> wrote:
>>>>
>>>>
>>>>> On Mar 16, 2018, at 1:35 PM, Jeffrey Sheen <jeffrey.sheen00@alumni.imperial.ac.uk > wrote:
>>>>>
>>>>> Dear list,
>>>>>
>>>>> I have a project that I am porting to macOS that uses the GTK+ stack, specifically pango+cairo+fontconfig.
>>>>>
>>>>> The code relies on being able to create `FcConfig' (fontconfig) objects and call `pango_fc_font_map_set_config' to bind them to pango.
>>>>>
>>>>> After following the build steps on the wiki, I found that the built product did not include the fontconfig libraries or headers, or the interop header files for pango.
>>>>>
>>>>> I was expecting to find `fontconfig/fontconfig.h' and `pango/pangofc-fontmap.h'.
>>>>>
>>>>> Is there a build setting that I must alter/add to target fontconfig?
>>>>>
>>>>> Jeff.
>>>>>
>>>>> N.B. I had previously asked this question to gtk-osx-devel-list, but was redirected to gtk-osx-users-list.
>>>>
>>>> For code like that there's meta-gtk-osx-freetype. Add that to your module list or make it a dependency of your app's module.
>>>>
>>>> However, if you have commit on the project it would be more portable to *not* use fontconfig objects so that Pango can use the native font backends on platforms other than X11.
>>>>
>>>> Regards,
>>>> John Ralls
>>>>
>>>>
>>>>
>>>
>>
>>
>