Static build on Mac building but not running

[remaininlight]

After some wrangling Axiom is building statically on my Mac but when it runs I get:

"/Users/user/Bounce/groove-axiom/cmake-build-static-debug/editor/backend/standalone/Axiom Standalone.app/Contents/MacOS/Axiom Standalone"
2018-11-14 12:37:39.243647+0000 Axiom Standalone[51624:456889] ASSERT failure in QVariant: "Trying to construct an unknown type", file kernel/qvariant.cpp, line 1136
Signal: SIGABRT (signal SIGABRT)

Which occurs when QVariant::create is called with type QVariant::Brush (66).
In order to get static linking working I referred to this:
http://doc.qt.io/qt-5/osx-deployment.html
But when not using QMake it seems that many libraries and macOS frameworks must be linked in CMake.
Any ideas about what might be causing the current runtime error would be useful. A possible clue is that HandlersManager::registerHandler in qvariant.cpp is never called, so perhaps the Brush type is never being registered for some reason?

I also get these warnings on build:

ld: warning: direct access in function 'std::__1::__function::__func<llvm::orc::RTDyldObjectLinkingLayer::ConcreteLinkedObject<std::__1::shared_ptr<llvm::RuntimeDyld::MemoryManager>, std::__1::shared_ptr<llvm::JITSymbolResolver>, llvm::orc::RTDyldObjectLinkingLayer::addObject(std::__1::shared_ptr<llvm::object::OwningBinary<llvm::object::ObjectFile> >, std::__1::shared_ptr<llvm::JITSymbolResolver>)::'lambda'(std::__1::__list_iterator<std::__1::unique_ptr<llvm::orc::RTDyldObjectLinkingLayerBase::LinkedObject, std::__1::default_delete<llvm::orc::RTDyldObjectLinkingLayerBase::LinkedObject> >, void*>, llvm::RuntimeDyld&, std::__1::shared_ptr<llvm::object::OwningBinary<llvm::object::ObjectFile> > const&, std::__1::function<void ()>)>::finalize()::'lambda'(), std::__1::allocator<llvm::orc::RTDyldObjectLinkingLayer::ConcreteLinkedObject<std::__1::shared_ptr<llvm::RuntimeDyld::MemoryManager>, std::__1::shared_ptr<llvm::JITSymbolResolver>, llvm::orc::RTDyldObjectLinkingLayer::addObject(std::__1::shared_ptr<llvm::object::OwningBinary<llvm::object::ObjectFile> >, std::__1::shared_ptr<llvm::JITSymbolResolver>)::'lambda'(std::__1::__list_iterator<std::__1::unique_ptr<llvm::orc::RTDyldObjectLinkingLayerBase::LinkedObject, std::__1::default_delete<llvm::orc::RTDyldObjectLinkingLayerBase::LinkedObject> >, void*>, llvm::RuntimeDyld&, std::__1::shared_ptr<llvm::object::OwningBinary<llvm::object::ObjectFile> > const&, std::__1::function<void ()>)>::finalize()::'lambda'()>, void ()>::target(std::type_info const&) const' from file '../../../../compiler/target/debug/libcompiler.a(OrcCBindings.cpp.o)' to global weak symbol 'typeinfo name for llvm::orc::RTDyldObjectLinkingLayer::ConcreteLinkedObject<std::__1::shared_ptr<llvm::RuntimeDyld::MemoryManager>, std::__1::shared_ptr<llvm::JITSymbolResolver>, llvm::orc::RTDyldObjectLinkingLayer::addObject(std::__1::shared_ptr<llvm::object::OwningBinary<llvm::object::ObjectFile> >, std::__1::shared_ptr<llvm::JITSymbolResolver>)::'lambda'(std::__1::__list_iterator<std::__1::unique_ptr<llvm::orc::RTDyldObjectLinkingLayerBase::LinkedObject, std::__1::default_delete<llvm::orc::RTDyldObjectLinkingLayerBase::LinkedObject> >, void*>, llvm::RuntimeDyld&, std::__1::shared_ptr<llvm::object::OwningBinary<llvm::object::ObjectFile> > const&, std::__1::function<void ()>)>::finalize()::'lambda'()' from file '../../../compiler/llvmmaxim/libllvm_axiom.a(LLVMMaxim.cpp.o)' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in function 'std::__1::__function::__func<llvm::orc::RTDyldObjectLinkingLayer::ConcreteLinkedObject<std::__1::shared_ptr<llvm::RuntimeDyld::MemoryManager>, std::__1::shared_ptr<llvm::JITSymbolResolver>, llvm::orc::RTDyldObjectLinkingLayer::addObject(std::__1::shared_ptr<llvm::object::OwningBinary<llvm::object::ObjectFile> >, std::__1::shared_ptr<llvm::JITSymbolResolver>)::'lambda'(std::__1::__list_iterator<std::__1::unique_ptr<llvm::orc::RTDyldObjectLinkingLayerBase::LinkedObject, std::__1::default_delete<llvm::orc::RTDyldObjectLinkingLayerBase::LinkedObject> >, void*>, llvm::RuntimeDyld&, std::__1::shared_ptr<llvm::object::OwningBinary<llvm::object::ObjectFile> > const&, std::__1::function<void ()>)>::finalize()::'lambda'(), std::__1::allocator<llvm::orc::RTDyldObjectLinkingLayer::ConcreteLinkedObject<std::__1::shared_ptr<llvm::RuntimeDyld::MemoryManager>, std::__1::shared_ptr<llvm::JITSymbolResolver>, llvm::orc::RTDyldObjectLinkingLayer::addObject(std::__1::shared_ptr<llvm::object::OwningBinary<llvm::object::ObjectFile> >, std::__1::shared_ptr<llvm::JITSymbolResolver>)::'lambda'(std::__1::__list_iterator<std::__1::unique_ptr<llvm::orc::RTDyldObjectLinkingLayerBase::LinkedObject, std::__1::default_delete<llvm::orc::RTDyldObjectLinkingLayerBase::LinkedObject> >, void*>, llvm::RuntimeDyld&, std::__1::shared_ptr<llvm::object::OwningBinary<llvm::object::ObjectFile> > const&, std::__1::function<void ()>)>::finalize()::'lambda'()>, void ()>::target_type() const' from file '../../../../compiler/target/debug/libcompiler.a(OrcCBindings.cpp.o)' to global weak symbol 'typeinfo for llvm::orc::RTDyldObjectLinkingLayer::ConcreteLinkedObject<std::__1::shared_ptr<llvm::RuntimeDyld::MemoryManager>, std::__1::shared_ptr<llvm::JITSymbolResolver>, llvm::orc::RTDyldObjectLinkingLayer::addObject(std::__1::shared_ptr<llvm::object::OwningBinary<llvm::object::ObjectFile> >, std::__1::shared_ptr<llvm::JITSymbolResolver>)::'lambda'(std::__1::__list_iterator<std::__1::unique_ptr<llvm::orc::RTDyldObjectLinkingLayerBase::LinkedObject, std::__1::default_delete<llvm::orc::RTDyldObjectLinkingLayerBase::LinkedObject> >, void*>, llvm::RuntimeDyld&, std::__1::shared_ptr<llvm::object::OwningBinary<llvm::object::ObjectFile> > const&, std::__1::function<void ()>)>::finalize()::'lambda'()' from file '../../../compiler/llvmmaxim/libllvm_axiom.a(LLVMMaxim.cpp.o)' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in function 'std::__1::__function::__func<llvm::orc::RTDyldObjectLinkingLayer::ConcreteLinkedObject<std::__1::shared_ptr<llvm::RuntimeDyld::MemoryManager>, std::__1::shared_ptr<llvm::JITSymbolResolver>, llvm::orc::RTDyldObjectLinkingLayer::addObject(std::__1::shared_ptr<llvm::object::OwningBinary<llvm::object::ObjectFile> >, std::__1::shared_ptr<llvm::JITSymbolResolver>)::'lambda'(std::__1::__list_iterator<std::__1::unique_ptr<llvm::orc::RTDyldObjectLinkingLayerBase::LinkedObject, std::__1::default_delete<llvm::orc::RTDyldObjectLinkingLayerBase::LinkedObject> >, void*>, llvm::RuntimeDyld&, std::__1::shared_ptr<llvm::object::OwningBinary<llvm::object::ObjectFile> > const&, std::__1::function<void ()>)>::getSymbolMaterializer(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >)::'lambda'(), std::__1::allocator<llvm::orc::RTDyldObjectLinkingLayer::ConcreteLinkedObject<std::__1::shared_ptr<llvm::RuntimeDyld::MemoryManager>, std::__1::shared_ptr<llvm::JITSymbolResolver>, llvm::orc::RTDyldObjectLinkingLayer::addObject(std::__1::shared_ptr<llvm::object::OwningBinary<llvm::object::ObjectFile> >, std::__1::shared_ptr<llvm::JITSymbolResolver>)::'lambda'(std::__1::__list_iterator<std::__1::unique_ptr<llvm::orc::RTDyldObjectLinkingLayerBase::LinkedObject, std::__1::default_delete<llvm::orc::RTDyldObjectLinkingLayerBase::LinkedObject> >, void*>, llvm::RuntimeDyld&, std::__1::shared_ptr<llvm::object::OwningBinary<llvm::object::ObjectFile> > const&, std::__1::function<void ()>)>::getSymbolMaterializer(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >)::'lambda'()>, llvm::Expected<unsigned long long> ()>::target(std::type_info const&) const' from file '../../../../compiler/target/debug/libcompiler.a(OrcCBindings.cpp.o)' to global weak symbol 'typeinfo name for llvm::orc::RTDyldObjectLinkingLayer::ConcreteLinkedObject<std::__1::shared_ptr<llvm::RuntimeDyld::MemoryManager>, std::__1::shared_ptr<llvm::JITSymbolResolver>, llvm::orc::RTDyldObjectLinkingLayer::addObject(std::__1::shared_ptr<llvm::object::OwningBinary<llvm::object::ObjectFile> >, std::__1::shared_ptr<llvm::JITSymbolResolver>)::'lambda'(std::__1::__list_iterator<std::__1::unique_ptr<llvm::orc::RTDyldObjectLinkingLayerBase::LinkedObject, std::__1::default_delete<llvm::orc::RTDyldObjectLinkingLayerBase::LinkedObject> >, void*>, llvm::RuntimeDyld&, std::__1::shared_ptr<llvm::object::OwningBinary<llvm::object::ObjectFile> > const&, std::__1::function<void ()>)>::getSymbolMaterializer(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >)::'lambda'()' from file '../../../compiler/llvmmaxim/libllvm_axiom.a(LLVMMaxim.cpp.o)' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in function 'std::__1::__function::__func<llvm::orc::RTDyldObjectLinkingLayer::ConcreteLinkedObject<std::__1::shared_ptr<llvm::RuntimeDyld::MemoryManager>, std::__1::shared_ptr<llvm::JITSymbolResolver>, llvm::orc::RTDyldObjectLinkingLayer::addObject(std::__1::shared_ptr<llvm::object::OwningBinary<llvm::object::ObjectFile> >, std::__1::shared_ptr<llvm::JITSymbolResolver>)::'lambda'(std::__1::__list_iterator<std::__1::unique_ptr<llvm::orc::RTDyldObjectLinkingLayerBase::LinkedObject, std::__1::default_delete<llvm::orc::RTDyldObjectLinkingLayerBase::LinkedObject> >, void*>, llvm::RuntimeDyld&, std::__1::shared_ptr<llvm::object::OwningBinary<llvm::object::ObjectFile> > const&, std::__1::function<void ()>)>::getSymbolMaterializer(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >)::'lambda'(), std::__1::allocator<llvm::orc::RTDyldObjectLinkingLayer::ConcreteLinkedObject<std::__1::shared_ptr<llvm::RuntimeDyld::MemoryManager>, std::__1::shared_ptr<llvm::JITSymbolResolver>, llvm::orc::RTDyldObjectLinkingLayer::addObject(std::__1::shared_ptr<llvm::object::OwningBinary<llvm::object::ObjectFile> >, std::__1::shared_ptr<llvm::JITSymbolResolver>)::'lambda'(std::__1::__list_iterator<std::__1::unique_ptr<llvm::orc::RTDyldObjectLinkingLayerBase::LinkedObject, std::__1::default_delete<llvm::orc::RTDyldObjectLinkingLayerBase::LinkedObject> >, void*>, llvm::RuntimeDyld&, std::__1::shared_ptr<llvm::object::OwningBinary<llvm::object::ObjectFile> > const&, std::__1::function<void ()>)>::getSymbolMaterializer(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >)::'lambda'()>, llvm::Expected<unsigned long long> ()>::target_type() const' from file '../../../../compiler/target/debug/libcompiler.a(OrcCBindings.cpp.o)' to global weak symbol 'typeinfo for llvm::orc::RTDyldObjectLinkingLayer::ConcreteLinkedObject<std::__1::shared_ptr<llvm::RuntimeDyld::MemoryManager>, std::__1::shared_ptr<llvm::JITSymbolResolver>, llvm::orc::RTDyldObjectLinkingLayer::addObject(std::__1::shared_ptr<llvm::object::OwningBinary<llvm::object::ObjectFile> >, std::__1::shared_ptr<llvm::JITSymbolResolver>)::'lambda'(std::__1::__list_iterator<std::__1::unique_ptr<llvm::orc::RTDyldObjectLinkingLayerBase::LinkedObject, std::__1::default_delete<llvm::orc::RTDyldObjectLinkingLayerBase::LinkedObject> >, void*>, llvm::RuntimeDyld&, std::__1::shared_ptr<llvm::object::OwningBinary<llvm::object::ObjectFile> > const&, std::__1::function<void ()>)>::getSymbolMaterializer(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >)::'lambda'()' from file '../../../compiler/llvmmaxim/libllvm_axiom.a(LLVMMaxim.cpp.o)' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.

[cpdt]

Hey, thanks for looking into this. At this point I'm honestly not sure what's going on... Axiom itself doesn't use QVariant so it seems like Qt's using it for something internally. I'm really not sure what the solution would be here, sorry :/

Also yeah, I kinda regret setting this project up with CMake instead of QMake... although I think it's a bit too late to change now. Oh well.

Yeah, I'm aware of those warnings, they happen whenever I build on Mac too. As far as I'm aware they're harmless, I haven't actually looked into what's causing them though. Just going by the warning message they've got something to do with linking LLVM, so I don't think they're related the the problems you're having.

[remaininlight]

It is now linking statically on macOS but when I try to load it as a VST plugin into Ableton Live or Bitwig it crashes in two different, mysterious ways. I spent some time trying to get it working with QMake but I think you made the right choice to use CMake.. I couldn't find any way of getting QMake to integrate with CMake, which seems to be a major flaw.

Looking around the internet it seems Qt is not a stable choice for VST plugins on macOS (https://stackoverflow.com/questions/12805084/qt-gui-environment-in-a-dll-vst-plugin for one). I think maybe some sort of wrapper involving JUCE might be a way to go?

Also, I dug out an old Windows laptop and tried to build Axiom on it but I get:

axiom\editor\compiler\interface\Frontend.h(4): fatal error C1083: Cannot open include file: 'unistd.h': No such file or directory

Why is it trying it include unistd.h? My understanding is this is a Unix file, yet you have it working on Windows?

[cpdt]

I normally use GCC in Mingw-w64 to build on Windows, since it makes it considerably easier to maintain cross-compatibility on other OSes. I do occasionally run it through MSVC just to make sure everything's working, although I haven't done that in a while so I'm not surprised there are a few places that don't build at the moment. Regarding that specific header, I'm not sure why that's even included at all, I'll remove it.

That's a bit annoying regarding Qt on macOS for VSTs. It looks like QMacNativeWidget might be a possible workaround - even if it's a bit unstable at least it's something? In the long term it's starting to look like it would be a good idea to move away from Qt due to these problems, but that would be quite a lot of work.

[cpdt]

Hey, sorry I haven't been able to look into this more recently. I've had a bit of a think, and I think I've come up with a solution which, although being kinda hacky, should allow the VST to run on Mac.

Basically, the idea is we use a really lightweight VST that starts Axiom running in another process, and they communicate over shared memory. I don't think this should be too hard to implement, and I'll try to look at it ASAP since I need Mac support for some other work now too :)

Will let you know the results.