build error with clang (macOS)

[ra1nb0w]

I am trying to update the port on macports but unfortunately the build fail with error: templates must have C++ linkage using clang. Full log at this gist.

Versions used:

• codec2 b1ff0a55 (from macports)
• lpcnetfreedv d97a3529 (from macports)
• freedv-gui 7cd03db

Software used:

• macOS 10.14.6 18G84
• Xcode 10.3 10G8
• Apple LLVM version 10.0.1 (clang-1001.0.46.4)

codec2 and lpcnetfreedv build correctly from macports. Just a mismatch on the name of lpcnetfreedv on cmake find_package but this is another story.

There is some placement errors on CMakeLists.txt and Info.plist but I will make a PR after this issue.

[drowe67]

Hello @ra1nb0w - yes some other people tried a macOS build a few months ago but hit compiling issues. Previous versions have built OK. Thanks for taking a look into this.

[ghost]

The choice of using complex.h versus comp.h may have tied us to GNU C. I think GCC is available for the Mac. I don't know how good the marriage is. Maybe a Docker container for Mac is an option.

[ra1nb0w]

I tried with gcc and it builds fine but it fails on startup with segmentation fault with address 0x00000000. I need to investigate more deeply because sometimes I see some custom printf sometimes not; maybe the problem is a mismatch linking between libraries build with clang and the app with gcc (I saw strange behaviour in the past).
Just one question: why do you choose complex.h over comp.h limiting the scope to gcc?
Anyway, I see the include of comp.h in cmake.
thanks

[ghost]

Just one question: why do you choose complex.h over comp.h limiting the scope to gcc?
Anyway, I see the include of comp.h in cmake.
thanks

I knew we would have API calls using the comp.h so we allowed for that, but the ease of translation from octave was pretty much the only driving force. I couldn't tell if David liked it early on, but I guess we got used to complex.h functions as the program got larger.

We were able to write a fast dft() and idft() in high level code, without resorting to kiss_fft. Adding two numbers is "a + b" and not something obfuscated like:

ans.real = a.real + b.real;
ans.imag = a.imag + b.imag;

The way it is now, it will be easier to translate it to RUST :-)

[drowe67]

Actually I didn't know complex.h was a gcc-only thing. Having said that - we had freed-gui 1.3.0 building for the mac just last year and it used complex.h, perhaps that used gcc on the mac.

[ghost]

I used it because most C compilers are C99 or better these days. I don't think it's GCC only. CLANG is a different thing and I don't think they are interested in C99 compatibility.

[drowe67]

OK thanks. Yes the use of complex.h is a fine choice Steve, and if it's standards based all the better. I'm very pleased with that modem.

[ra1nb0w]

ok. thanks for all information.

[darksidelemm]

@ra1nb0w if you get this working at all, please let me know - I've hit exactly the same issues you have, and short of re-building all my macports dependencies using gcc (which I'm not even sure is possible), I'm stuck.

[ra1nb0w]

No, I didn't do any progress on clang build for lack of time and because at prime sight it is not so trivial. For gcc seems the entry point or something related but, as maintainer on macports, I don't like to follow this path and force gcc; therefore the only way that I like is to fix clang build.
Maybe we can join forces ;-)

[ra1nb0w]

see https://github.com/drowe67/codec2/pull/66