Forums > Dev

Max 5.1.1 SDK doesn't like x86_64 compilation?

May 11, 2010 | 5:37 pm

Hi

I may have missed something: are we able to compile 64-bit externals (or at least universal binaries that are 32 and 64-bit compatible) using Max 5.1.1 SDK now online?

I’m getting errors such as:

ld: warning: in DriverMAX.def, file was built for unsupported file format which is not the architecture being linked (x86_64)
ld: warning: in /Library/Frameworks//MaxAPI.framework/MaxAPI, missing required architecture x86_64 in file
ld: warning: in /Applications/Max5/MaxSDK-5.0.6r2/c74support/max-includes/MaxAPI.lib, file was built for unsupported file format which is not the architecture being linked (x86_64)

Which would seem to indicate this API build is 32-bit only?

David


May 11, 2010 | 8:59 pm

What exactly are you trying to achieve?

MaxMSP is a 32 bit app – the externals run in the application address space and so cannot be 64 bit.

The operating system may or may not be running in 64 bit – that doesn’t make a difference.

So I can’t (at the present time) see any reason to have a 64 bit version of an external.

Regards

Alex


May 11, 2010 | 9:24 pm

Alex is correct — Max is a 32-bit app with 32-bit binaries, including frameworks, and does not support 64-bit binaries at this time.

Cheers


May 12, 2010 | 1:00 pm

Well this is certainly just ignorance on my part, I’m sure, but all I’m trying to do is compile 10.6 externals, which rely on fftw3 and libsndfile, both of which were compiled under arch x86_64 flags.

The thing is, when I try to compile the external, everything goes ok (as in, ld links things alright) until the Max framework, which as I understand now, breaks x86_64 because it is strictly 32-bit, am I right?

So but this means that in a makefile, I can’t specify i386 -and- x86_64 as arch flags to gcc because x86_64 will always break?

It seemed to me that, because 10.6 is x86_64 (right?), in order to compile for 10.6, I -have- to use that arch flag.

Am I wrong? Anyone have a working unix-like makefile for 10.6 I can learn from?

David


May 12, 2010 | 1:12 pm

Just to follow up, doing -arch i386 compiles only, against 32-bit versions of libsndfile.a and libfftw3.a, gives the following error:


g++ -bundle -undefined suppress -flat_namespace -o soundspotter~.mxo DriverMAX.def -ggdb -DMAC_VERSION -DMAC_EXT_VERSION -arch i386 -g -O2 -pipe -no-cpp-precomp -framework CoreFoundation -framework Carbon -framework CoreServices -framework MaxAPI /Applications/Max5/MaxSDK-5.1.1/c74support/max-includes/MaxAPI.lib /Applications/Max5/MaxSDK-5.1.1/c74support/msp-includes/MaxAudio.lib /usr/local/lib/libsndfile.a /usr/local/lib/libfftw3.a "-Wl,-syslibroot,/Developer/SDKs/MacOSX10.6.sdk" DriverMAX.o DriverCommon.o CircularMatrix.o MatchedFilter.o Matcher.o SoundFile.o SoundSpotter.o FeatureExtractor.o
ld: warning: in DriverMAX.def, file was built for unsupported file format which is not the architecture being linked (i386)
ld: warning: in /Applications/Max5/MaxSDK-5.1.1/c74support/max-includes/MaxAPI.lib, file was built for unsupported file format which is not the architecture being linked (i386)
ld: warning: in /Applications/Max5/MaxSDK-5.1.1/c74support/msp-includes/MaxAudio.lib, file was built for unsupported file format which is not the architecture being linked (i386)

Which clearly at this point isn’t about x86_64 compilation, right?

Just to be specific, here’s the Makefile I’m using:

HOME=/Users/dpc
MAXMSPSDK=/Applications/Max5/MaxSDK-5.1.1/c74support

SDK="-isysroot /Developer/SDKs/MacOSX10.6.sdk"
SDKLIB="-Wl,-syslibroot,/Developer/SDKs/MacOSX10.6.sdk"

LIBSNDFILEDIR=/usr/local/lib
LIBFFTW3DIR=/usr/local/lib

INCDIR=-I$(MAXMSPSDK)/max-includes -I$(MAXMSPSDK)/msp-includes -I$(LIBSNDFILEDIR) -I$(LIBFFTW3DIR)

LIBS=$(MAXMSPSDK)/max-includes/MaxAPI.lib $(MAXMSPSDK)/msp-includes/MaxAudio.lib /usr/local/lib/libsndfile.a /usr/local/lib/libfftw3.a $(SDKLIB)

FRAMEWORKS=-framework CoreFoundation -framework Carbon -framework CoreServices -framework MaxAPI

# Set one of these to true
FFMPEG=true
SNDFILE=

# Conditional soundfile library
# default library is libsndfile
ifeq ($(FFMPEG),true)
     FFMPEGDIR=/usr/local/lib
     SNDFILELIB=libavformat.a libavcodec.a libavutil.a -lm -lbz2 -lz
     SNDFILEOBJS=ffmpeginterface.o
     INCDIR+=
     LIBDIR+=-L.
     SNDFILEFLAGS=-DFFMPEG
else
     LIBSNDFILEDIR=$(HOME)/src/libsndfile
     SNDFILELIB=-lsndfile
     SNDFILEOBJS=
     INCDIR+=-I$(LIBSNDFILEDIR)
     LIBDIR+=-L$(LIBSNDFILEDIR)
     SNDFILEFLAGS=-DLIBSNDFILE
endif

DRIVER=DriverMAX
EXECUTABLE=soundspotter~
LIBRARY=$(EXECUTABLE).mxo

LIBOBJS=$(DRIVER).o DriverCommon.o CircularMatrix.o MatchedFilter.o Matcher.o SoundFile.o SoundSpotter.o FeatureExtractor.o

F90FLAGS='-O2'
CFLAGS=-ggdb -DMAC_VERSION -DMAC_EXT_VERSION -arch i386 -g -O2 -pipe -no-cpp-precomp
CCFLAGS="-arch i386 -g -Os -pipe $SDK"
LDFLAGS=""

SHARED_LIB_FLAGS=-bundle -undefined suppress -flat_namespace

CC = g++

.PHONY: all clean test

all: $(EXECUTABLE)

$(EXECUTABLE): $(LIBRARY)

$(LIBOBJS): %.o: %.cpp *.h
	g++ -c $(CFLAGS) $(INCDIR) -Wall $(FRAMEWORKS) $< %.o: %.cpp *.h
	g++ -c $(CFLAGS) $(INCDIR) -Wall $(FRAMEWORKS) $<

$(LIBRARY): $(LIBOBJS)
	g++ $(SHARED_LIB_FLAGS) -o $(LIBRARY) $(DRIVER).def $(CFLAGS) $(FRAMEWORKS) $(LIBS) $^ 

clean:
	-rm $(LIBOBJS)
	-rm $(LIBRARY)

May 12, 2010 | 1:16 pm

Also, linking against 10.4 SDK instead of 10.6 SDK does not make a difference (same error).


May 12, 2010 | 2:01 pm

>> It seemed to me that, because 10.6 is x86_64 (right?), in order to compile for 10.6, I -have- to use that arch flag.

No – you shouldn’t have an issue compiling for 32 bit only (which is the right approach to take). 32 bit apps can be run by a 64 bit OS. I compile from XCode so I can’t advise on your makefile issues. My only guess is maybe to do with having old build files somewhere? Can you clean the build (like in XCode), or delete any intermediate build files – that might work…..

In addition I would advise against compiling against the 10.6 SDK unless you need to, especially if you intend to distribute your external as many people are still on 10.4 or 10.5.

A.


May 12, 2010 | 5:03 pm

Until someone more knowledgeable comes along, I’d say you have (at least) two problems here.

1) You need to link against 32-bit .dylibs of FFTW and Libsndfile. You can’t link 32-bit code against 64-bit dynamic libraries.

2) In your Makefile’s LIB definition, you’re supplying files (MaxApi.lib, etc.) that probably shouldn’t be linked against. The MaxApi is a Framework, and even if you were linking to dynamic libraries on OSX, they’d be suffixed .dylib, not .lib.

HTH, Charles


May 12, 2010 | 11:47 pm

Actually AFAIK the MaxApi.lib (and all .lib files of the SDK) are the Windows-builds of the Max et al libraries. If you are on OS X, simply ignore them…


May 13, 2010 | 5:38 pm

Thanks everybody. Still getting:

g++ -bundle -undefined suppress -flat_namespace -o soundspotter~.mxo DriverMAX.def -ggdb -DMAC_VERSION -DMAC_EXT_VERSION -arch i386 -g -O2 -pipe -no-cpp-precomp -framework CoreFoundation -framework Carbon -framework CoreServices -framework MaxAPI /usr/local/lib/libsndfile.a /usr/local/lib/libfftw3.a "-Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk" DriverMAX.o DriverCommon.o CircularMatrix.o MatchedFilter.o Matcher.o SoundFile.o SoundSpotter.o FeatureExtractor.o
ld: warning: in DriverMAX.def, file was built for unsupported file format which is not the architecture being linked (i386)
Talmach:so

But now at least the 64-bit errors are gone…might even go back to xcode now I now the differences, etc. And yes, the pointers to .lib files from LIB was a mistake and is now gone…

David


May 13, 2010 | 7:30 pm

David-

I’d look at the linkage of the fftw.a and sndfile.a files. My guess is they’re in COFF and not MACH format. Your builds of both libraries should have produced .dylibs, so I’d try to link to those. That’s what Apple wants you to do.

(I’m assuming that all your .o files were produced on the Mac, and have a high likelihood of being MACH. If not, suspect COFF there as well.)

((Running "file" against the object files, libs and archives should tell you what format they are.))

(David? Pland? late of #Dataflow?)

HTH, Charles


March 8, 2011 | 4:34 pm

i got the same problem, should i compile again the fftw3 library or what is the way to follow to compile the external?


March 9, 2011 | 3:39 pm

Here is a link that goes through the process for libsndfile (which is likely similar to what you need to do with fftw):

http://redmine.jamoma.org/projects/dsp/wiki/SoundFileLib

Hope you have a lot of patience,
Tim


March 10, 2011 | 11:23 am

i solved the fftw3 problem with a step more in the fftw3 installation process:

$ export CFLAGS="-arch i386"
$ ./configure
$ make
# make install

and now i can build my external and it works.

i don’t know if it’s the perfect workflow but it works for me.


Viewing 14 posts - 1 through 14 (of 14 total)