OSX Build problems

[Tomaz Canabrava]

On Tue, Mar 15, 2016 at 3:16 PM, Jeroen Massar <jeroen at massar.ch> wrote:

> On 2016-03-15 18:59, Dirk Hohndel wrote:
> > 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.
>
> Shite happens, good that I have a thick skin (keeps me quite warm most
> of the time as well, unfortunately not warm enough to not need a thick
> piece of neoprene when diving Swiss lakes ;)
>
> >> 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.
>
> Yep, I am going against master.
>
> The build script nicely pulls in the relevant other repos, which is a
> useful thing to do.
>
> >> 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.
>
> Adding: set(CMAKE_VERBOSE_MAKEFILE ON) to the CMakeLists.txt makes me a
> bit wiser that there seems to be a detection issue on my box, as the
> actual compile command is:
>
> cd /Users/jeroen/git/subsurface/subsurface/build/subsurface-core &&
>
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
> -DBT_SUPPORT -DQT_BLUETOOTH_LIB
> [... lots of stuff ...]  -I/usr/include/libxml2 [... more stuff ]
>  -c /Users/jeroen/git/subsurface/subsurface/subsurface-core/cochran.c
> In file included from
> /Users/jeroen/git/subsurface/subsurface/subsurface-core/cochran.c:12:
> /Users/jeroen/git/subsurface/subsurface/subsurface-core/dive.h:38:10:
> fatal error: 'libxml/tree.h' file not found
>
>
> yeah... that is not going to work, as /usr/include/ really does not
> exist on this box ;)
>
> I will figure out why/how it thinks that is correct.
>
>
> Note btw that the homebrew version of libxml2 is not linked in
> /usr/local/ per default, thus I don't think that cmake will find it
> either even if you have it installed, as:
>
>  /usr/local/Cellar/libxml2/2.9.3/lib/cmake/libxml2/libxml2-config.cmake
>  /usr/local/Cellar/libxml2/2.9.3/lib/pkgconfig/libxml-2.0.pc
>

I found this while searching for the cmake stuff for brew, maybe it helps?
http://stackoverflow.com/questions/1487752/how-do-i-instruct-cmake-to-look-for-libraries-installed-by-macports

usually I just add the LD_LIBRARY_PATH, DLYB_LIBRARY_PATH and PATH pointed
to the brew bin and lib dirs, this makes CMake works correctly most of the
time

are definitely outside the cmake search path.
>
> I'll read up on how:
> /usr/local/Cellar/cmake/3.5.0/share/cmake/Modules/FindLibXml2.cmake
>
> gets used, as that discovers the include path and obviously that goes
> wrong on my box.
>
> [..]
> >> 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.
>
> I have had this exact situation: 100 people complain, and then when you
> have had it, you reply to person 101 who actually was not ;)
>
> Happens, next!
>
> [..]
> >> 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.
>
> No worries ;)
>
> Greets,
>  Jeroen
>
>
>
>
> _______________________________________________
> subsurface mailing list
> subsurface at subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20160315/7eb1ee06/attachment-0001.html>