Emerson

Undefined symbols for architecture x86_64:

ld: symbol(s) not found for architecture x86_64

clang: error: linker command failed with exit code 1 (use -v to see invocation)

(On macOS 10.14.4 with XCode 11.3, project settings kept as distributed with Max-SDK-8.0.3)

Undefined symbols for architecture x86_64:
  "__common_symbols"
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Hello, I'm getting this linker error:
Undefined symbols for architecture x86_64:
  "__common_symbols"
ld: symbol(s) not found for architectu

linker-error

There have been a couple of notifications about similar problems in the forum, and they are usually solved with upgrades. It doesn't look applicable in this case.

The error message references the function in my source where I tried to use the code example from the MaxAPI.pdf page 254: "36.8.3.1 Creating a Dictionary from JSON".

@EMERSON We would probably have to take a look at how your project is set up. Are you including maxmspsdk.xcconfig in your project?

Side note, Xcode 11+ will fail if you try to build a 32-bit extern (or FAT extern), and the SDK projects all assume this. There may be other Xcode 11 issues as well...

@EMERSON We would probably have to take a look at how your project is set up. Are you including maxmspsdk.xcconfig in your project? 

@BEN BRACKEN Thanks, here's the project file.

patry.xcodeproj.zip

Does your problem go away when you include commonsyms.c in your project?

@EMERSON
Does your problem go away when you include commonsyms.c in your project?


@BEN BRACKEN Yes, when I included "common/commonsyms.c" the linking problem went away indeed, thanks! 

As I could now try the external: Max quits when I send the JSON text into the object. The unexpected thing is, I couldn't even find the chance to test the risky couple of lines I had added to the MaxAPI.pdf's example on page 254, because this line alone (from the example)

t_object *jsonreader = (t_object*)object_new(_sym_nobox, _sym_jsonreader);

Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000001c38

Termination Signal: Segmentation fault: 11

Termination Reason: Namespace SIGNAL, Code 0xb

(I can paste the full report if it is useful)

(About the inclusion of maxmspsdk.xcconfig, I didn't make any changes to that when coupling the project from SDK with the new source, but the "project navigator" on the left pane shows the xcconfig file under the project, so I guess it is included. Upon your note about the architecture type and Xcode version conflict, I tried both with the out-of-the package settings where maxmspsdk.xcconfig has ARCHS = x86_64 in two lines and Project Format: XCode 3.2-compatible, and then modifying these to ARCHS = x64 and XCode 11.0-compatible, and both work. I don't know which setting I should keep.)

@BEN BRACKEN  Yes, when I included "common/commonsyms.c" the linking problem went away indeed, thanks! 
As I could now try the external: Max quits when I send the JSON text into the object. The unexpected thing is, I couldn't even find the chance to test the risky couple of lines I had added to the MaxAPI.pdf's example on page 254, because this line alone (from the example)

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000000001c38
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Segmentation fault: 11
Termination Reason:    Namespace SIGNAL, Code 0xb
Terminating Process:   exc handler [773]

Definitely useful to see the full crash report! Not sure where to start otherwise...

In max-external->build settings, be sure that your "valid architectures" only have x86_64 listed, and "architectures" is set to 64-bit Intel.

Again, Xcode 11 may not be fully supported with the standard Max-SDK. If you do find problems, please make an issue over on the GitHub issue tracker:

https://github.com/Cycling74/max-sdk/issues

Side note, you may want to experiment with the Min-DevKit:

Again, Xcode 11 may not be fully supported with the standard Max-SDK. If you do find problems, please make an issue over on the GitHub issue tracker:
https://github.com/Cycling74/max-sdk/issues 

Side note, you may want to experiment with the Min-DevKit:
https://github.com/Cycling74/min-devkit 

About "commonsyms.c", I may have to mention that I included it in the source by adding line #include "common/commonsyms.c", not by listing it as a second source under the project; does this differ? (I heard it differs on some IDE's)

In max-external->build settings, I edited "valid architectures" from i386 x86_64 to x86_64, and changed "architectures" from "Standard Architectures 64-bit Intel" to "64-bit Intel" from the menu. 

report-1.txt

In max-external->build settings, I edited "valid architectures" from i386 x86_64 to x86_64, and changed "architectures" from "Standard Architectures 64-bit Intel" to "64-bit Intel" from the menu. 
Here's the crash report from before:

And here's the crash report after changing architectures in build settings:

report-2.txt

I strongly recommend downloading and installing Max 8.1.2:

Are you restarting Max after recompiling the external?

Also, what exact text are you sending your object? Probably best to post a snippet of your code so other users can help you debug!

I strongly recommend downloading and installing Max 8.1.2:
https://cycling74.com/downloads 

I guess I should do the update, but would it not suffice to update to the version before 8.1.2? (I guess 8.0.8 is available for download.) There were many issues posted (for instance, with node.js with which I'm actively developing something), so that it feels scary to install 8.1.2.

I guess I should do the update, but would it not suffice to update to the version before 8.1.2? (I guess 8.0.8 is available for download.) There were many issues posted (for instance, with node.js with which I'm actively  developing something), so that it feels scary to install 8.1.2.

I'm restarting Max after rebuilding each time.

You will probably have to call common_symbols_init() in ext_main(), as well...

Linker error