Visual Studio 2015 link error
I'm porting some of my audio externals from Mac to Windows, using Visual Studio 2015 on Windows 7 and max-sdk-7.1.0. The externals are C++ throughout. Several of them ported with minimal alterations, and they work fine. But one of them is giving me a serious problem at the linker stage. The error I get is this...
1> Creating library ..\..\sysbuild\intermediate\Release_Win32\jg.granulate~\jg.granulate~.lib and object ..\..\sysbuild\intermediate\Release_Win32\jg.granulate~\jg.granulate~.exp
1>granulate~.obj : error LNK2001: unresolved external symbol __common_symbols
I am not using commonsyms.h directly. Unlike the externals that work, this one uses buffers, with the latest API, including the required buffer~ notification method. I wonder if there is some dependency on the _common_symbols ptr by the buffer functions I'm using. My issue might have something to do with C/C++ linkage differences and possibly my project settings.
To get a working .vcxproj for one of the externals that compiled and linked fine, I copied the .vcxproj from the simplemsp~ example in the SDK, let VS update it to a 2015 version, and made some changes so that VS could find my extra headers and what not. I also told it to compile my files as C++ rather than C. Perhaps there is a setting I'm getting wrong, though I have diff'd the .vcxproj I'm using with the one for the advanced/collect SDK example, which is also C++, and didn't see any clearly important differences.
I'll hack away at this again when I get back to the Windows machine I was using, but does anyone know of obvious things that might cause this link error, when other C++ projects do not?
Thanks!
John
An addendum...
I noticed on the Mac that undefined global symbols in the binary for my problematic external include __common_symbols (declared extern in max-includes/commonsyms.h), whereas that was missing from one of the externals that was not problematic on Windows.
I further noticed that only my code for the problematic external calls atom_getsym(), and that this function is documented as capable of returning _sym_getname, which is one of the symbols in the __common_symbols array. The externals that linked with no issue do not call atom_getsym and do not reference __common_symbols (according to the nm command-line program).
So I'm guessing that could be the source of my problem, but I'm still not sure why Visual Studio can't find __common_symbols.
Do I need to wrap the declarations of the functions in my C++ file that call into the MaxAPI with BEGIN_USING_C_LINKAGE/END_USING_C_LINKAGE ? I've never had to do that on the Mac.
John
Doh! I *am* explicitly using _sym_nothing (which is what I meant to type when I wrote "_sym_getname" in my last post) in my code.
So all I have to do is add max-includes/common/commonsyms.c to my project? Still links properly in Xcode when I do that. I notice that __common_syms is missing from the MaxAPI dylib, so that must be the solution. Wonder why it works in Xcode without it.
Sorry for this monologue. If anyone is following me and can confirm anything about commonsyms.c, please do.
John
Okay, I also see the bit about calling common_symbols_init(). I'll update this thread if my problem is solved. I should've known about this, but somehow haven't run into it before. Still a little confused why my source linked in Xcode without including commonsyms.c in my project.
J
Just confirming that my problem was failing to include commonsyms.c in my project (and calling common_symbols_init() in ext_main()).
John, your monologue helped me understanding (somehow) my problem. So thanks!
I wanted to use _sym_list (in a XCode project!), and had to follow the procedure you proposed.
Now I wonder wether it's not easier to define a static t_symbol with gensym("list") in ext_main() and use it instead.
Ha, ha! Yeah, I probably should have held my fire until I could figure it out better. In the end, it was quite a simple issue.
I'm not sure about your _sym_list question, I'm afraid.
John, it's the future calling.... your monologue just saved me hours of frustration, so thanks for doing that! I would never have figured that out on my own. :-)