OSX Build problems

[Dirk Hohndel]

On Tue, Mar 15, 2016 at 06:42:21PM +0100, Jeroen Massar wrote:
> [TLDR: Full intent to provide proper patches, but I need it then to
> build first as then I can debug the real problem: why the heck I get
> segfaults when just running the tool and asking it to download from my
> watch ;)  --- note the smileys and good intentions throughout... ]

Excellent! Sorry for my grumpy email.

> On 2016-03-15 18:20, Dirk Hohndel wrote:
> >>
> >> I've been attempting to build subsurface also for a bit, with little
> >> success. The dctool indeed hit me, but as per IRC, that was easily
> >> circumvented... The QT thing seems to be way more annoying though.
> > 
> > The funny thing is - we have about four people (optimistically speaking)
> > who build on Mac and two who build for Windows (one ON Windows). So to me
> > it constantly feels like I am spending a LOT of time on making sure
> > everyone can build for not a lot of value.
> 
> Understood, hence why my target is to, when the build works, do a clean
> build to make sure the build instructions are sane for everybody who
> follows and provide those details so that it can be replicated.

Looking forward to that. I assume you are building master and not
v4.5-branch - I may want to make sure I track your patches for that as
well so it's easier to build 4.5.4.

> I just did not get a full build going yet, and as I noticed the patch
> for the path of Qt, thought I add my few intermediary cents just in case
> somebody else knew how to attack the problem.

Since there are a few of us who have builds going, I'm sure we can figure
this out.

> >> My current list of homebrew build depends is quite a bit more than on
> >> the website:
> >> brew qt5 install automake autoconf libtool libusb libssh2 pkgconfig hidapi
> > 
> > So let's fix that.
> > Oh, that's not complete, either. It misses asciidoc (ok, I guess one could
> > call that optional) and cmake (definitely not optional).
> > 
> > OK, done.
> 
> Great, thanks.
> 
> As noted, will test on an empty OSX install and then record all the
> individual steps when I get it build, thus making sure that rebuilding
> will be easy peasy for everybody in the future.

add libxml2 to that list and see if that fixes your problem with the
include path.


> >> The QT part I fixed in my build with (build.sh):
> >> 8<-------------------
> >>         elif [ -d "~/Qt/5.6" ] ; then
> >>                 export CMAKE_PREFIX_PATH=~/Qt/5.6/clang_64/lib/cmake
> >> +       elif [ -d /usr/local/opt/qt5/lib ] ; then
> >> +               export CMAKE_PREFIX_PATH=/usr/local/opt/qt5/lib/cmake
> > 
> > Is that the default path with homebrew? I have my own Qt installation
> > instead of the homebrew one
> 
> Homebrew does not touch user's home dirs, it installs systemwide, thus
> /usr/local/Cellar/qt5/5.5.1_2/ for that version, with symlinks in
> /usr/local/ in various places to glue that all in place.
> 
> I think this is also likely where a lot of differences in the build can
> occur: people using "local Qt" and then "homebrew" and then of course
> lingering files. Hence my intent of a "clean" OSX install to make sure
> we catch all the corners. As noted, proper patches to follow...

For a while we asked people to build Qt from source because neither the
homebrew version nor the official Qt version worked. By now that's no
longer the case as either works fine. I still have a locally build Qt
because I'm testing against 5.6.0 (and I started doing that long before
there were official binaries for that). I definitely want to create the
Subsurface 4.5.4 binaries against Qt 5.6.0 - not sure when Homebrew will
update, though.

tl;dr: we need to build against either, so this patch makes a lot of
sense.

> >> The next problem though seems to be with libxml... apparently some
> >> include path is not being passed properly $somewhere... (and I have
> >> never been a fan of either autoconf/automake let alone cmake... but the
> >> fact that build.sh exists and does not catch several dependencies being
> >> missing underscores what I think about those "tools")
> > 
> > So fix them. It builds for me. It builds for Robert, it builds for Tomaz.
> > So if it doesn't build for you let's figure out why and fix it. The
> > passive aggressive '...what I think about those "tools"' doesn't really
> > encourage me to go out of my way to guess what might be wrong for you.
> 
> I primarily noted that in the style of "I have a learning curve to
> figure out what the heck is going wrong" :)

And I primarily responded in the style of "I'm pissed off by now".
Sorry about that.

> >> (Real path is of course the magically long
> >> version:
> >> /Application/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/libxml2/
> >> )
> > 
> > Oh well, let me guess anyway... I'm picking it up from homebrew it seems:
> > 
> > -I/usr/local/Cellar/libxml2/2.9.3/include/libxml2
> > 
> > Which makes me think that this might needed on the brew install line above
> > as well.
> 
> Well, there is indeed homebrew libxml (if one installs that) and then
> the system one.
> 
> The system one (well, Xcode) lives in the above path, seems the dylib is:
>  -rwxr-xr-x  1 root  wheel  2395024 Jan 14 03:05 libxml2.2.dylib
> 
> Thus that might run a bit behind 2.9.
> 
> Cmake/configure is picking it up though for subsurface, but the actual
> compile then fails in the end.

That's bad. But IIRC there were issues with the system provided libxml2
(at some point, with some version of Xcode) which is why I installed the
much newer Homebrew version.

> >> Watch out that one is really using "bash" and not any other kind of
> >> shell when executing the build.sh, as that might make a huge difference...
> > 
> > So call 
> > 
> > bash ./scripts/build.sh
> 
> The 'use bash' suggestion was a comment on the $HOME patch that is the
> start of this thread.

Actually, I'm kinda puzzled by all this. Here's what I get on my Mac:

$ sh --version
GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin15)

So the installed shell IS bash as far as I can tell. Apple typical it is a
wee bit ancient (I run 4.3.42 on Arch Linux).

> > $ git shortlog -s -n | egrep -i "jeroen|massar"
> > 
> > $ git shortlog -s -n | grep -i "hohndel"
> >   3799  Dirk Hohndel
> 
> Not a fair comparison really, me being the new user trying to help out.

Yes. I agree. That was cheap and uncalled for. My apologies.

/D