Tuesday, April 18, 2017

Administrative stuff

Writing the weekly report was a bit longer than usual due to the amount of information related to last week's meetings.

Jenkins

Still fighting my Jenkins basic builds (build, recorder, elfe).

• Failures in MinGW with some tests because .exe extension is not correctly added when executing the test program that was built.
• Failures in Cygwin with posix_memalign not found. This turns out to be a recent change in elfe switching to C++11 for the recorder (in order to get <atomic> which is how I now do atomics). The change was to use -std=c++11, but the posix_memalign is apparenlty considered a GNU extension on Cygwin for some reason. It's better to use -std=gnu++11 for consistency with C and C++ builds where GNU extensions are supported.
• Added AnsiColor module to Jenkins, so now I should have colored builds in the report, easier to read.

Spice updates

I restarted all my machines, and now I can connect again with spicy to guests on Muse or Shuttle. The Mac version of spicy shows no window, but a message indicating probably that some callbacks are missing:

(process:52354): Gtk-WARNING **: Locale not supported by C library.
	Using the fallback 'C' locale.
2017-04-18 18:15:44.694 spicy[52354:20980699] *** WARNING: Method userSpaceScaleFactor in class NSView is deprecated on 10.7 and later. It should not be used in new applications. Use convertRectToBacking: instead. 

(spicy:52354): Gdk-WARNING **: GdkQuartzDisplay does not implement the monitor vfuncs

Debugging with Xcode

Usually, I run my debug sessions within GNU Emacs. The GUD support is good enough, and I more or less know my way around GDB. But on a Mac, installing GDB and getting it to work is a real pain. For security reasons, Apple wants only signed executables to run as debuggers, so... Well, it's complicated, and last time I tried, even after going through all the hoops, it did not work well.

Apple's alternative is LLDB, which has an almost entirely incompatible command set with GDB. And a verbose one, at that. It's not too well integrated with Emacs either. So using Xcode as a front-end is probably the sane choice. But last time I had tried, I ran into an issue with how to start an executable not built with Xcode. I ended up attaching to a running program, which is not ideal.

It turns out that debugging an arbitrary executable with Xcode is not as complicated as I thought. You simply edit the "Scheme", modify the "Run" command to tell which executable you want to run, and that's basically it. Fastoche.

Rebuilding Spice for Mac

It's getting tiredsome to always have to re-create a proper build environment for spice-gtk for the Mac. Ended up with a simple script, build.sh that encapsulates my know-how on the topic:

#!/bin/bash

PATH=$PATH:/usr/local/Cellar/gettext/0.19.8.1/bin 
    CPPFLAGS="-I/usr/local/include -I/usr/local/Cellar/openssl/1.0.2j/include -I/usr/local/opt/jpeg-turbo/include" 
    LDFLAGS="-L/usr/local/lib -L/usr/local/Cellar/openssl/1.0.2j/lib -L/usr/local/opt/jpeg-turbo/lib" 
    ./configure --enable-vala $*

One of the things I positively love about autoconf is that, for all its gory complexity, it has targets to make pdf or make clean, make mostlyclean, make distclean... but no make debug!!! Building a debug-enabled executable is either all manual using CFLAGS and CXXFLAGS and LDFLAGS. Or you can reconfigure the project with --enable-debug. If the project has support for it.

But for Spice, if I do that, then for some reason the build fails to find libjpeg-turbo (despite it being in the path):

4 warnings generated.
channel-display-mjpeg.c:110:2: error: "You should consider building with
      libjpeg-turbo" [-Werror,-W#warnings]
#warning "You should consider building with libjpeg-turbo"
 ^
 

Hmmm.

Splitting the environment from my build script so that the variables can be set. Also moving the jpeg-turbo include first. That gives env.sh that looks like:

export PATH=$PATH:/usr/local/Cellar/gettext/0.19.8.1/bin
export CPPFLAGS=" -I/usr/local/opt/jpeg-turbo/include -I/usr/local/include -I/usr/local/Cellar/openssl/1.0.2j/include"
export LDFLAGS="-L/usr/local/lib -L/usr/local/Cellar/openssl/1.0.2j/lib -L/usr/local/opt/jpeg-turbo/lib"

and build.sh:

#!/bin/bash -x
. env.sh
./configure --enable-vala  $*
make -j8

Now channel-display-mjpeg passes. An error with snprintf in usbutil.c, fixed by moving the #include <stdio.h> outside of #ifdef __linux__ (not sure why it was there in the first place, nor why this apparently only matters with debug builds)

Next:

  CC       vncdisplaykeymap.lo
In file included from vncdisplaykeymap.c:95:
In file included from /usr/local/Cellar/gtk+3/3.22.7/include/gtk-3.0/gdk/gdkquartz.h:23:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/System/Library/Frameworks/AppKit.framework/Headers/AppKit.h:10:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:8:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSObjCRuntime.h:492:1: error: 
      expected identifier or '('
@class NSString, Protocol;
^

Ah, I already had that on March 10. Missing CFLAGS=-ObjC, fixed my env.sh to:

#!/bin/sh
export PATH=$PATH:/usr/local/Cellar/gettext/0.19.8.1/bin
export CFLAGS=-ObjC
export CPPFLAGS="-I/usr/local/opt/jpeg-turbo/include -I/usr/local/include -I/usr/local/Cellar/openssl/1.0.2j/include"
export LDFLAGS="-L/usr/local/opt/jpeg-turbo/lib -L/usr/local/lib -L/usr/local/Cellar/openssl/1.0.2j/lib"

Apparently, the actual CFLAGS are not taken under consideration by automake makefiles unless you set them before configure. How annoying.

Now I get:

  CC       spice-audio.lo
In file included from spice-audio.c:42:
./spice-channel-priv.h:23:10: fatal error: 'openssl/ssl.h' file not found
#include 
         ^

This is the kind of crap when you reboot and did not record all your ad-hoc build tricks in a script. Ah. Missing export in front of CPPFLAGS in my script, and stray {tt ""} at end, so the last -I option had a trailing export

Debugging installed executables does not work

I spent a couple of hours trying all kinds of things to try to get debugging information in my spicy executable. It turns out I had it since the beginning, but the make install strips them. So I can only debug the tools/.libs/spicy executable, not the one installed in location. Aaargh.