Build fail OS-X

[ReaddyEddy]

OSX home-brew x86_64 build:

set CMAKE_CXX_FLAGS_DEBUG -stdlib=libc++ -std=c++11 -fno-operator-names

still leaves error at: [ 47%] Building CXX object havoc/CMakeFiles/havoc.dir/hadamard.cpp.o In file included from ../Projects/2016_09_12_TuringCodec/turingcodec/havoc/hadamard.cpp:23: ../Projects/2016_09_12_TuringCodec/turingcodec/havoc/Jit.h:155:24: error: reinterpretcast from 'const uint8 ' (aka 'const unsigned char ') to 'int (_)(const unsigned char , long, const unsigned char , long)' casts away qualifiers return reinterpret_cast<F >(this->getCode());

[kupix]

Thanks Eddy, so far the codec is untested on OSX. You could also log the issue against upstream project havoc which is independently testable and runs on Travis-CI so could easily be integrated also on OSX. The assembler we use (xbyak) should work on Mac too. Looks like the error could be fixed with a const_cast.

[ReaddyEddy]

There's no pointer in the havoc subtree to the upstream project do you have one?

[kupix]

It's here https://github.com/kupix/havoc There is a chance it's an easy fix although I have a feeling porting the JIT assembly code to OS X calling/stack conventions/position-independent code may lead to further fun challenges.

[ReaddyEddy]

Thanks for the link to the parabola account: brew install xbyak Installing xbyak from homebrew/science ==> Downloading https://github.com/herumi/xbyak/archive/v4.70.tar.gz ==> Downloading from https://codeload.github.com/herumi/xbyak/tar.gz/v4.70 ######################################################################## 100.0% ==> make install PREFIX=/usr/local/Cellar/xbyak/4.70

[kupix]

btw, xbyak is a header-only project and havoc contains a copy of the necessary xbyak headers

[rensd]

Same issue here on OSX 10.10 installed xbyak, replaced reinterpret_cast for const_cast

[ 47%] Building CXX object havoc/CMakeFiles/havoc.dir/hadamard.cpp.o In file included from /Users/turing/src/turingcodec/havoc/hadamard.cpp:23: /Users/turing/src/turingcodec/havoc/Jit.h:155:24: error: const_cast to 'int (*)(const unsigned char *, long, const unsigned char *, long)', which is not a reference, pointer-to-object, or pointer-to-data-member return const_cast<F *>(this->getCode());

[ReaddyEddy]

My own view is that running a build in a virtual box is more productive than pursuing a dedicated OS-X build from my perspective just now.

[kodawah]

IMO this is a Very Bad Idea, at least half of the video community is using osx, and requesting to write portable code in 2016 is not completely unreasonable. At the very least you should leave this open and/or ask for patches.

[matteonaccari]

Further investigating the issue

[MarcAntoine-Arnaud]

I start to configure cross build using Travis (no really good history on the source branch). Normally you can see the same error here: https://travis-ci.org/MarcAntoine-Arnaud/turingcodec/jobs/175675149 It's very good to see when we fix something if it don't broke for an another platform.

[thom4parisot]

@chrisn had quite a good success making C programs being built on macOS and other Linux distributions (like CentOS/Amazon flavoured CentOS). Have a look at https://github.com/bbc/audiowaveform

[kupix]

@MarcAntoine-Arnaud - thankyou - are you (or @matteonaccari ) still looking at this? no worries if not, just would be useful to know if any work in progress here

[kasrinat]

Hello,

I am new to this project and do not yet have a good idea of the implementation. However, I am getting the same compile error on OSX 10.11 as in the Travis build referenced by @MarcAntoine-Arnaud .

Does it have something to do with getCode() returning both const uint8 type and template F type through different declarations?