OSX Build problems

[Jeroen Massar]

[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... ]

On 2016-03-15 18:20, Dirk Hohndel wrote:
> On Tue, Mar 15, 2016 at 04:32:37PM +0100, Jeroen Massar wrote:
>>>>
>>>> There are errors while building libdivecomputer, it tries also to
>>>> build examples/dctool_parse.c where in calls of the type
>>>> VENDOR_MODEL_parser_create a fourth parameter “serial” is missing. But
>>>> I guess since this is an example this is save to ignore.
>>>
>>> It is. But the best is to just remove the useless build of the
>>> examples... in the build.sh add "--disable-examples" to the configure
>>> call for libdivecomputer
>>>
>>>> More serious is in subsurface/scripts/build.sh
>> [..]
>>>> This does not find ~/Qt/5.5 for me on my Macs.
>>
>> 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.

> In general I appreciate patches or concise bug reports from those who
> actually try to do builds and for whom the builds fail.

Yep, full ack on that.

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.

>> 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.

>> 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...

[..]
>> 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 agree with your sentiment btw, fully understood. While tool X
might not be my ideal thing, it will just be another thing to figure out
and learn about.

[..]
>> (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.


>>>> I really don’t speak shell but it seems in that in the file test ~ is
>>>> not interpolated properly. If I replace it by $HOME it works. Here is
>>>> a patch that does this.
>>>
>>> Odd - it worked one of my Macs, but fails on the others. I don't think I
>>> installed a different shell but it's possible...
>>>
>>> Can you send a second patch to fix the problem above?
>>
>> 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.

I am using the bash call, as that is what is in the instructions (the
INSTALL file in the repo).

> Again - how much time do you think I want to spend on making sure this
> works out of the box on every OS on the face of the planet? 

As much time till it works consistently as it is in.

Hence why I noted to use a empty/clean OSX Install to make sure that it
works.

> Versus time I
> spend on working on the code, on releases, on the website, on the backend
> server, on answering support questions and on oh five hundred other things.
> 
> Complaining is cheap.

Please note that I was not complaining AT ALL...

I was only providing initial feedback on a similar issue that obviously
somebody else was running into too.

> $ 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.

I am fully fully fully aware of who sticks time in the code and
appreciate it immensely.

Hence why I am trying to ___dive__ in and provide some initial details.

As I noted, proper patch requests etc to follow.... but first got to
make it compile properly, then I'll make a clean VM and document what
steps are missing, what goes wrong and make patches based on that.

Greets,
 Jeroen