Thijs Koerselman

Is it possible to compile Max4 externals directly with the Max5 SDK?

I noticed the C74_MAX_SDK_VERSION define in the new examples which is set to 0x0506. When I compile an external which doesn't use any of the new Max5 functionality, can I compile it for Max 4 and 5 by linking to the same framework? Is there a need to set this definition to something like 0x0460?

The commonsymbols interface seems to have changed, so I guess I need to compile the Max4 objects with commonsyms-max4.* files?

cross-compiling-version-4-and-5

Headers and differing implementations can be handled by

But presumably you'd still need to conditionally add the correct Max 4 or Max 5 frameworks somehow, and they are both named "MaxAPI.framework". I don't know if XCode can handle something like that?

What we were thinking of doing is setting up a separate XCode project document for Max 4 & 5 (so frameworks, header search paths and build location can be different), but both project documents would live in the same project folder, sharing all the same source files via included #ifdefs as above.

Headers and differing implementations can be handled by 

What we were thinking of doing is setting up a separate XCode project document for Max 4 & 5 (so frameworks, header search paths and build location can be different), but both project documents would live in the same project folder, sharing all the same source files via included #ifdefs as above.


johnpitcairn wrote on Wed, 04 March 2009 18:44

Why not use the define thijs is taking about from the newest version of the SDK? This might be preferable:

There's no need to have two project files - 2 targets with different settings is all you need - I'm doing exactly that for anything that needs to be compiled against the 4 and 5 sdks separately - I don't experience any problems with frameworks with the same name - as long as the search pats and added frameworks are correct for each target.

You can definitely do it the other way round (compile against the 4 framework and then run in 5), if you don't need the functionality of 5. Setting the definition probably won't do anything, as I imagine it's just there so that those who wish to can determine which sdk they are compiling against. I haven't tried to compile against the 5 sdk and run in 4 though - why don't you try it out and see what happens?

johnpitcairn wrote on Wed, 04 March 2009 18:44Headers and differing implementations can be handled by 

johnpitcairn wrote on Wed, 04 March 2009 18:44
What we were thinking of doing is setting up a separate XCode project document for Max 4 & 5 (so frameworks, header search paths and build location can be different), but both project documents would live in the same project folder, sharing all the same source files via included #ifdefs as above.

AlexHarker wrote on Thu, 05 March 2009 09:00

I haven't tried to compile against the 5 sdk and run in 4 though - why don't you try it out and see what happens?

It's been working fine for me, so long as I don't use calls that are new to 5 (IIRC, the link list API is slightly different).

AlexHarker wrote on Thu, 05 March 2009 09:00
I haven't tried to compile against the 5 sdk and run in 4 though - why don't you try it out and see what happens?

It's been working fine for me, so long as I don't use calls that are new to 5 (IIRC, the link list API is slightly different). 

One tricky thing is that I'm also using a custom framework which links against the MaxAPI.framework. My objects link to both, so I think I'll have to create seperate 4 and 5 compatible versions. Maybe I can compile everything with Max5 SDK and the commonsyms_mac4.*

Some of my objects are only using Max4 functionality, others use the new jgraphics and such. I'll think about it for a bit and try a few things out.

One tricky thing is that I'm also using a custom framework which links against the MaxAPI.framework. My objects link to both, so I think I'll have to create seperate 4 and 5 compatible versions. Maybe I can compile everything with Max5 SDK and the commonsyms_mac4.* 

Some of my objects are only using Max4 functionality, others use the new jgraphics and such. I'll think about it for a bit and try a few things out. 

AlexHarker wrote on Thu, 05 March 2009 22:00

I hadn't noticed that define when I set it up - but the commonsyms define has worked happily for both versions of the Max 5 SDK so far.

Thanks for that Alex, I wasn't sure it would work without conflict. I'll need to cross-compile in a few days ... the other possible fly in the ointment is I need it to compile in XCode 3.x (work) and XCode 2.5 (home) at the moment, which adds another possible point of failure. Crossed fingers...

AlexHarker wrote on Thu, 05 March 2009 22:00Why not use the define thijs is taking about from the newest version of the SDK? This might be preferable:
#define C74_MAX_SDK_VERSION 0x0506

Quote:There's no need to have two project files - 2 targets with different settings is all you need - I'm doing exactly that for anything that needs to be compiled against the 4 and 5 sdks separately - I don't experience any problems with frameworks with the same name - as long as the search pats and added frameworks are correct for each target.

Thanks for that Alex, I wasn't sure it would work without conflict. I'll need to cross-compile in a few days ... the other possible fly in the ointment is I need it to compile in XCode 3.x (work) and XCode 2.5 (home) at the moment, which adds another possible point of failure. Crossed fingers...


I have been struggling with different approaches over the last days and finally came up with a solution that I like.

Owen mentioned that you can link against the sdk5 and still run the objects in max4. I can confirm that this works, assuming you don't use any of the new sdk5 functionality. This new functionality, however, does include the altered commonsyms interface.

I tried to compile my objects with the commonsyms_max4, but kept getting linking errors because _common_symbols was not defined. (_common_symbols is the new symbols table which is part of sdk5)

I then discovered that this linking error occurred because the ext_obex header includes commonsyms.h. The workaround I found for this is to simply comment-out the include statement in ext_obex (line 60).

The nice thing about this setup, is that I can now compile all of my objects (both 4 and 5) from a single project linking only to the new SDK. It makes me wonder though, what is the intended use of commonsyms_max4.*? Is the include in ext_obex a "bug"?

For my own framework (a utility thing which is used by multiple objects) I have now compiled 2 versions (A and B) with one restricting to Max4 only stuff. The Max4 / backwards-compatible objects link to A and the Max5-only objects link to B. Both frameworks are then merged into one so I only have to distribute a single framework.

I hope this info is useful to others. I would like to know what people or c74 have to say about the ext_obex commonsyms issue.

/**
This macro being defined means that getbytes and sysmem APIs for memory management are unified. This is correct for Max 5, but should be commented out when compiling for old max targets.
@ingroup memory
*/
#define MM_UNIFIED


Do I need to command this out? Is it better to compile different versions of objects for Max4 and Max5 then?

I have been struggling with different approaches over the last days and finally came up with a solution that I like. 

Do I need to command this out? Is it better to compile different versions of objects for Max4 and Max5 then?


Cross-compiling version 4 and 5