> On Apr 17, 2019, at 1:41 PM, Pascal <[email protected]> wrote: > >> >> Le 16 avr. 2019 à 16:10, John Ralls <[email protected]> a écrit : >> >>> On Apr 16, 2019, at 3:56 AM, Pascal <[email protected]> wrote: >>> >>>> Le 15 avr. 2019 à 22:31, John Ralls <[email protected]> a écrit : >>>> >>>>> On Apr 15, 2019, at 12:59 PM, Pascal <[email protected]> wrote: >>>>> >>>>> John, I've found some suspicious instructions in jhbuildrc line 321: >>>>> if (_osx_version < 14): >>>>> module_extra_env["expat"] = {'CFLAGS':os.environ['CFLAGS'] + ' -arch >>>>> i386 -arch x86_64'} >>>>> module_extra_env.update( >>>>> {"perl-xml-simple":{"ARCHFLAGS":"-arch i386 -arch x86_64"}, >>>>> "perl-xml-parser":{"ARCHFLAGS":"-arch i386 -arch x86_64"}}) >>>>> >>>>> I run macOS 10.13.6. >>>>> Without theses lines all is fine now. >>>>> What are them for? >>>> >>>> They're because pre-10.14 perl was distributed with a combined i386/x86_64 >>>> library, so perl-xml-simple and perl-xml-parser needed to be built that >>>> way in order to link, and since they depend on expat it did too. >>>> >>>> Are you using Xcode or command line tools? What version? What does `perl >>>> -V` say about flags (first line under Compiler)? >>> >>> Hello John, >>> >>> I've both installed: >>> $ xcodebuild -version >>> Xcode 10.1 >>> Build version 10B61 >>> $ pkgutil --pkg-info=com.apple.pkg.CLTools_Executables >>> package-id: com.apple.pkg.CLTools_Executables >>> version: 10.1.0.0.1.1539992718 >>> $ xcrun --find gcc >>> /Applications/Xcode.app/Contents/Developer/usr/bin/gcc >>> $ which gcc >>> /usr/bin/gcc >>> $ perl -V >>> Summary of my perl5 (revision 5 version 18 subversion 2) configuration: >>> Compiler: >>> cc='cc', ccflags ='-arch x86_64 -arch i386 -g -pipe -fno-common >>> -DPERL_DARWIN -fno-strict-aliasing -fstack-protector', >> >> Pascal, >> >> I looked at the module sets again. perl-xml-simple and perl-xml-parser were >> there because gtk-doc used to require them. It doesn't any more (it was >> rewritten in python), so I took them out of bootstrap.modules and forgot to >> take them out of jhbuildrc. That means that expat doesn't need a universal >> build anymore. I've pushed a fixed jhbuildrc-gtk-osx to pipenv. >> >> That aside you may have some problems at runtime with the 10.14 SDK and >> MAC_OS_X_VERSION_MIN_REQUIRED=101300. It depends on whether Apple has >> updated any of the non-framework libraries that we use between the two >> versions. Unfortunately the stub linking introduced in 10.9 doesn't >> completely mask all of the symbol changes between library versions. > > John, > > I ran the new jhbuildrc-gtk-osx at pipenv with success though conftest still > crash from bison build (bison-3.0.4). > > I used XDG_CONFIG_HOME, it is ok for me. > But $HOME/.cache is still used for building, how to move it to my specific > build folder ?
Pascal, Try setting buildroot in your jhbuildrc-custom. (I like to set a source, build, and inst directory under a project directory, for example ~/Development/Gramps-build/gramps-stable-git-Mojave/). In theory setting buildroot=None should force source directory builds, but it doesn't seem to work consistently for me, some targets are building in source and others in ~/.caches. It's probably something in my rather complex jhbuildrc-custom that I stare at and don't see. Regards, John Ralls _______________________________________________ gtk-osx-users-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list
