Hi,

I can confirm that the fixes  by Mooneer resolve the compile errors. I
was able to get travis to almost finish the build:

https://travis-ci.org/db4ple/freedv-gui/builds/570441603?utm_source=github_status&utm_medium=notification

Compile is okay, just the program which then builds the MacOS X app
package fails, but this is difficult to fix for me with each Travis
build taking more than 10 mins.
But for those with a Mac, the .travis.yml found here:
https://github.com/db4ple/freedv-gui/blob/macosx/.travis.yml can serve
as a blueprint. If you find a solution for the final problem, let me
know and I integrate this in .travis.yml

FYI: Travis uses homebrew instead of Mac Ports.
I have no idea (and no way to test) if the resulting program made by
Travis does work at all or if it crashes like the build made by Mooneer.

Regards,
Danilo


On 11 Aug 2019 09:02, Mooneer Salem wrote:
> Hi all,
>
> It turns out that the placement of extern "C" in some of the Codec2
> include files was causing FreeDV build issues for me on 10.14, in
> addition to the previously mentioned ofdm_stack issue. I created a
> pull request for those changes: https://github.com/drowe67/codec2/pull/66
>
> Also, I have the freedv binary itself building in my forked version
> (https://github.com/tmiw/freedv-gui) but the app bundle task for some
> reason is needing me to manually enter library names. The binary is
> additionally segfaulting on startup with the following backtrace:
>
> * thread #1, queue = 'com.apple.main-thread', stop reason =
> EXC_BAD_ACCESS (code=1, address=0x2816820)
>
>   * frame #0: 0x0000000100680d21
> libwx_osx_cocoau_core-3.0.dylib`wxApp::CallOnInit() + 149
>
>     frame #1: 0x0000000100b80068 libwx_baseu-3.0.dylib`wxEntry(int&,
> wchar_t**) + 37
>
>     frame #2: 0x0000000100039593 freedv`main(argc=1,
> argv=0x00007ffeefbff938) at fdmdv2_main.cpp:171:1
>
>     frame #3: 0x00007fff68b5c3d5 libdyld.dylib`start + 1
>
>     frame #4: 0x00007fff68b5c3d5 libdyld.dylib`start + 1
>
>
>  I'll have to do additional investigation for those issues but if
> anyone wants to try it, I adapted build_linux.sh for OSX (and named
> build_osx_macports.sh in my repo.
>
> Thanks,
>
> -Mooneer K6AQ
>
> On Sat, Aug 10, 2019 at 10:35 PM Danilo Beuche <[email protected]
> <mailto:[email protected]>> wrote:
>
>     Hi Mark,
>
>     I realized that now, my „mistake“. Nevertheless,   I learned
>     through that exercise how to use Travis with MacOS. Will try (!)
>     to get FreeDV-GUI going as well through Travis but this is a
>     fairly tedious process without access to a Mac so I won’t promise
>     that I‘ll achieve anything.
>
>     Regards
>     Danilo
>
>     Am 11.08.2019 um 01:14 schrieb Mark Jessop
>     <[email protected] <mailto:[email protected]>>:
>
>>     Hi Danilo, 
>>
>>     I can build codec2 just fine (with the ofdm_stack changes) - It's
>>     really freedv-gui where the build issues raise their head. 
>>
>>     Cheers,
>>     Mark
>>
>>     On Sun, Aug 11, 2019 at 4:15 AM Danilo Beuche
>>     <[email protected] <mailto:[email protected]>> wrote:
>>
>>         Hi Mark,
>>
>>         I am experimenting right now with a MacOS X build via travis
>>         for codec2 in my GitHub clone of codec2. So far it looks
>>         mostly good. The build works, all tests are built and being
>>         run. 5 tests fail. Out of these 5 failing tests are 4
>>         valgrind tests for memory leaks, these need to be looked at
>>         but for this one needs are real MacOS machine (which I don't
>>         have, I just let Travis run one machine for me.). The last
>>         tests probably needs also only a minor tweak in the build
>>         configuration. So generally the build works if minor
>>         modifications are made and the environment is similar to the
>>         one created for the Travis build:
>>
>>         https://github.com/db4ple/codec2/pull/2/files
>>
>>         You can also checkout the last build log from Travis:
>>
>>         
>> https://travis-ci.org/db4ple/codec2/builds/570275451?utm_source=github_status&utm_medium=notification
>>
>>         The STM32 fails on Travis as well, but this is not a concern
>>         at the moment.
>>
>>         Regards,
>>         Danilo
>>
>>
>>         On 10 Aug 2019 05:37, Mark Jessop wrote:
>>>         Is there anyone out there who has been able to successfully
>>>         build the latest git freedv / codec2 master branches under OSX?
>>>
>>>         The instructions
>>>         here: https://github.com/drowe67/freedv-gui/blob/master/README.osx
>>>         are now of course 100% out of date with the recent updates,
>>>         and probably need to be marked as such so others don't try
>>>         and follow them and fall into a trap.
>>>
>>>         A few notes so far:
>>>
>>>         - LPCNet builds fine with the recent-ish changes to look for
>>>         AVX extensions under OSX.
>>>
>>>         - The ofdm_stack target in codec2 won't compile using clang,
>>>         as it doesn't have the -no-pie and -Map options. I had to
>>>         wrap the ofdm_stack target in unittest/CMakeLists.txt in a
>>>         if (NOT APPLE) directive so it wouldn't be built. Once this
>>>         is done codec2 builds fine. 
>>>
>>>         The cmake command for freedv ends up being: cmake
>>>         -DCMAKE_BUILD_TYPE=Debug
>>>         -DCODEC2_BUILD_DIR=/Users/darkside/Dev/codec2-git/build
>>>         -DLPCNET_BUILD_DIR=/Users/darkside/Dev/LPCNet_test/build
>>>         
>>> -DWXCONFIG=/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/lib/wx/config/osx_cocoa-unicode-3.0
>>>         ..
>>>
>>>         Compiling freedv itself is where I run into all sorts of fun
>>>         errors, which i've pasted here:
>>>         https://slexy.org/view/s2r4g9MkjG
>>>
>>>         I suspect these are related to clang's supplied libc++.
>>>         Looking at the CMakeLists.txt file for freedv, it looks like
>>>         someone has encountered something similar in the
>>>         past: 
>>> https://github.com/drowe67/freedv-gui/blob/master/CMakeLists.txt#L98
>>>
>>>         Not really sure where to go from here, short of attempting
>>>         to completely recompile macports using gcc instead of clang,
>>>         which is something I suspect will result in my sanity
>>>         degrading further than it already has this morning.
>>>
>>>         Hopefully there's someone else out there that has looked
>>>         into this, or has actually been successful in getting this
>>>         to work!
>>>
>>>         73
>>>         Mark VK5QI
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>         _______________________________________________
>>>         Freetel-codec2 mailing list
>>>         [email protected] 
>>> <mailto:[email protected]>
>>>         https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>>         _______________________________________________
>>         Freetel-codec2 mailing list
>>         [email protected]
>>         <mailto:[email protected]>
>>         https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>>
>>     _______________________________________________
>>     Freetel-codec2 mailing list
>>     [email protected]
>>     <mailto:[email protected]>
>>     https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>     _______________________________________________
>     Freetel-codec2 mailing list
>     [email protected]
>     <mailto:[email protected]>
>     https://lists.sourceforge.net/lists/listinfo/freetel-codec2
>
>
>
> _______________________________________________
> Freetel-codec2 mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/freetel-codec2
_______________________________________________
Freetel-codec2 mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Reply via email to