thanks Oli.
I think I have something working now!
So first off, I had tried the static library route and found loads of errors.
Things like
:
ndefined symbols for architecture i386:
".objc_class_name_NSAppleScript", referenced from:
pointer-to-literal-objc-class-name in libStaticJuce.a(juce_core.o)
".objc_class_name_NSArray", referenced from:
pointer-to-literal-objc-class-name in libStaticJuce.a(juce_core.o)
So if you look at this post:
http://www.juce.com/forum/topic/juce-static-library-includes-link-nsapp
it appears that this is caused by requiring the Cocoa framework to be linked, i.e. in the Build Phases, link Binary with Libraries, add Cocoa.framework. Similarly,
Undefined symbols for architecture i386:
"_vDSP_vclr", referenced from:
juce::FloatVectorOperations::clear(float*, int) in libStaticJuce.a(juce_audio_basics.o)
is due to requiring the Acclerate frameworks for DSP.
(So these dependencies are not included when you build a static library?)
the method to build the static lib, is to create one using the Introjucer, and then find that in Build/Debug of teh static library project; add that in build phases, link binary with libraries, as with the in-built OS X frameworks.
So then I have a command line tool!
Then turn to the Max external. I added Accelerate and Cocoa to get down to 28 mysterious errors. This kind of thing:
Undefined symbols for architecture x86_64:
"std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::__init(char const*, unsigned long)", referenced from:
juce::String::toStdString() const in libStaticJuce.a(juce_core.o)
"std::__1::basic_ostream<char, std::__1::char_traits<char> >::~basic_ostream()", referenced from:
juce::NumberToStringConverters::StackArrayStream::writeDouble(double, int) in libStaticJuce.a(juce_core.o)
"std::__1::basic_ostream<char, std::__1::char_traits<char> >::operator<<(double)", referenced from:
juce::NumberToStringConverters::StackArrayStream::writeDouble(double, int) in libStaticJuce.a(juce_core.o)
"std::__1::basic_streambuf<char, std::__1::char_traits<char> >::sync()", referenced from:
It seems that migt be due to use of the wrong compiler, Gromit. this post seemed to indicate such a thing:
http://stackoverflow.com/questions/24891962/yaml-cpp-link-error-on-macos-and-gcc-4-8
so I switched compiler to use libc++
and the external now compiles!
any thoughts on why the compiler did need changing from libstdc++, could be helpful.
thanks Oli for getting back!