> On Apr 14, 2019, at 12:50 PM, Pascal <p....@orange.fr> wrote: > >> >> Le 14 avr. 2019 à 19:14, John Ralls <jra...@ceridwen.us> a écrit : >> >>> On Apr 14, 2019, at 8:48 AM, Pascal <p....@orange.fr> wrote: >>> >>> Hello John, >>> >>> Based on gtk-osx-setup.sh installation from last week, I run 'jhbuild >>> bootstrap" (just to give a try ;-), as you wrote in Readme it ran into >>> error with the lack of "xz" in my case, so I ran "jhbuild -m >>> /path/to/gtk-osx/modulesets-stable/bootstrap.modules build meta-bootstrap" >>> with more success. >>> >>> But I had 2 errors: >>> 1) One conftest crashed during bison 3.0.4 configure, see screen capture >>> below: >>> <Capture d’écran 2019-04-14 à 10.37.21.png> >>> The crash log displays: >>> "Application Specific Information: >>> %%n used in a non-immutable format string: %s" >>> I don't know if it relevant. >>> How to catch it more precisely? >>> >>> 2) One error during expat 2.2.0 configure: >>> checking for gcc... /Applications/Xcode.app/Contents/Developer/usr/bin/gcc >>> checking for gcc... /Applications/Xcode.app/Contents/Developer/usr/bin/gcc >>> checking whether the C compiler works... no >>> configure: error: in `/Users/blady/.cache/jhbuild/build/expat-2.2.0': >>> configure: error: C compiler cannot create executables >>> When running inside jhbuild shell it gives: >>> checking for gcc... /Applications/Xcode.app/Contents/Developer/usr/bin/gcc >>> checking whether the C compiler works... yes >>> >>> So I've selected option 4 start shell and ran configure manually >>> (.jhbuild-srcdir/configure --prefix ...) and then selected option 2 ignore >>> error and continue to build. >>> But I have more errors: >>> *** Building expat *** [18/25] >>> make -j 5 >>> make: *** No rule to make target `lib/xmlparse.c', needed by >>> `lib/xmlparse.lo'. >>> >>> So I've selected option 4 start shell and ran make manually. >>> Then the same with install: >>> *** Installing expat *** [18/25] >>> make >>> DESTDIR=/Volumes/Snowy-HD/Users/blady/Documents/Programmation/GIT/xnadalib-2019/_jhbuild/root-expat >>> install >>> make: *** No rule to make target `xmlwf/xmlwf.c', needed by >>> `xmlwf/xmlwf.o'. Stop. >>> >>> So I've selected option 4 start shell and ran make install manually. >>> Where am I wrong? >> >> Hmm, both built for me yesterday without complaint, though that was in a >> 10.9 VM with command line tools instead of Xcode. >> >> I don't know, I need to see more from conftest crash log and to see the >> actual reason that gcc failed. The first you can copy from the report in >> Console, the second will be in >> /Users/blady/.cache/jhbuild/expat-2.2.0/config.log. >> >> From the crash log get everything from the top to the first 10 frames of the >> stack trace. >> >> From config.log find the line "checking whether the C compiler works" and >> copy everything from that line to "result: no". > > John, > > 1) Here is backtrace of crash log: > Crashed Thread: 0 Dispatch queue: com.apple.main-thread > Exception Type: EXC_CRASH (SIGABRT) > Exception Codes: 0x0000000000000000, 0x0000000000000000 > Exception Note: EXC_CORPSE_NOTIFY > Termination Reason: LIBSYSTEM, [0x2] > Application Specific Information: > %%n used in a non-immutable format string: %s > Thread 0 Crashed:: Dispatch queue: com.apple.main-thread > 0 libsystem_kernel.dylib 0x00007fff6d1eeeb6 __abort_with_payload > + 10 > 1 libsystem_kernel.dylib 0x00007fff6d1e92b8 > abort_with_payload_wrapper_internal + 89 > 2 libsystem_kernel.dylib 0x00007fff6d1e92e5 abort_with_payload + > 9 > 3 libsystem_c.dylib 0x00007fff6d0ffecc _os_crash_fmt + 182 > 4 libsystem_c.dylib 0x00007fff6d1368a8 __vfprintf + 16526 > 5 libsystem_c.dylib 0x00007fff6d15b059 __v2printf + 473 > 6 libsystem_c.dylib 0x00007fff6d14034b _vsnprintf + 415 > 7 libsystem_c.dylib 0x00007fff6d1403fe vsnprintf + 80 > 8 libsystem_c.dylib 0x00007fff6d1700ad __sprintf_chk + 142 > 9 conftest 0x000000010d4b3f2f main + 79 > 10 libdyld.dylib 0x00007fff6d09f015 start + 1 > > 2) Here is expat config.log: > <config_expat.log>
Pascal, The vsnprintf assert is an Apple "feature" for security. Gtk-osx's bootstrap.modules patches bison to avoid the bug, and I'm close to updating to the latest bison in which that's fixed. Rerun bootstrap and when bison fails pick "wipe directory and start over" so that the patch applies. For expat it looks like you've got both -arch i386 and -arch x86_64 somehow. That doesn't work, you have to build libraries twice and then merge them, but you don't really want to do that; just build for x86_64. Regards, John Ralls _______________________________________________ gtk-osx-users-list mailing list gtk-osx-users-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list
