Re: [gtk-osx-users] New build system (continued).





On Apr 14, 2019, at 12:50 PM, Pascal <p p14 orange fr> wrote:


Le 14 avr. 2019 à 19:14, John Ralls <jralls ceridwen us> a écrit :

On Apr 14, 2019, at 8:48 AM, Pascal <p p14 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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]