xcode dependencies are not smart about 32 vs 64 bit...

[ofZach]

I'm seeing a behavior where if you build OF 0.9 as 32 bit, but through a new project choose 64 bit, it doesn't understand that the compiled OF lib is not the right architecture and attempts to link it. You get a clear warning and then some linking errors. Might it make sense to have the OF project build both 32 and 64 bit libs, or be a little bit smarter? If you clean and rebuilt it's ok, since it will rebuild OF as 64 bits.

ld: warning: ignoring file /Users/zachlieberman/Documents/openframeworks/git/openFrameworks/libs/openFrameworksCompiled/lib/osx/openFrameworksDebug.a, file was built for archive which is not the architecture being linked (x86_64): /Users/zachlieberman/Documents/openframeworks/git/openFrameworks/libs/openFrameworksCompiled/lib/osx/openFrameworksDebug.a
Undefined symbols for architecture x86_64:
  "typeinfo for ofBaseSoundInput", referenced from:
      typeinfo for ofBaseApp in main.o
  "ofBaseSoundOutput::audioOut(float*, int, int, int, unsigned long long)", referenced from:
      vtable for ofBaseApp in main.o
      vtable for ofApp in ofApp.o
  "ofBaseSoundInput::audioIn(ofSoundBuffer&)", referenced from:
      vtable for ofBaseApp in main.o
      vtable for ofApp in ofApp.o
  "typeinfo for ofBaseSoundOutput", referenced from:
      typeinfo for ofBaseApp in main.o
  "ofBaseSoundInput::audioIn(float*, int, int)", referenced from:
      vtable for ofBaseApp in main.o
      vtable for ofApp in ofApp.o
  "ofBaseSoundOutput::audioOut(float*, int, int)", referenced from:
      vtable for ofBaseApp in main.o
      vtable for ofApp in ofApp.o
  "ofBaseSoundOutput::audioOut(ofSoundBuffer&)", referenced from:
      vtable for ofBaseApp in main.o
      vtable for ofApp in ofApp.o
  "ofSetupOpenGL(int, int, ofWindowMode)", referenced from:
      _main in main.o
  "vtable for ofBaseSoundOutput", referenced from:
      ofBaseSoundOutput::ofBaseSoundOutput() in main.o
  NOTE: a missing vtable usually means the first non-inline virtual member function has no definition.
  "ofBaseSoundInput::audioIn(float*, int, int, int, unsigned long long)", referenced from:
      vtable for ofBaseApp in main.o
      vtable for ofApp in ofApp.o
  "vtable for ofBaseSoundInput", referenced from:
      ofBaseSoundInput::ofBaseSoundInput() in main.o
  NOTE: a missing vtable usually means the first non-inline virtual member function has no definition.
  "ofRunApp(ofBaseApp*)", referenced from:
      _main in main.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

[ofZach]

also good to note that if you have more than one project that has the openframeworks library open, clean doesn't actually clean the OF library. (it will clean the lib if can see the OF dependency project as navigable (ie, it's the first open project with the OF lib dependency), ie, this will work

but if there's no triangle, you can't clean the openframeworksLib project to rebuild with the right architecture. this means that it's hard to fix this problem via clean in some cases...

[arturoc]

we could probably compile the OF library as a universal binary as we do with other libraries?

and yes the dependency on the project is kind of broken in the sense that only one project can rebuild it, clean it... if you have 2 projects open and you are doing changes in the OF library itself you need to rebuild from the project that has open the OF library which can be confusing sometimes.

not sure what's the solution for this, i think the reason xcode does this is to avoid problems if you try to build a project at the same time from more than one place. i've seen similar behaviours in other IDEs and build systems recently and the way they usually solve it is by building the dependencies locally as we used to do some time ago but that makes the builds huge.

anyway not sure what's the best solution for this

[danoli3]

Maybe a switch to Workspaces rather than embedded project in project.

http://stackoverflow.com/questions/21631313/xcode-project-vs-xcode-workspace-differences

[ofTheo]

@arturoc @ofZach its super easy to build a universal lib.
Nothing changes except switching build active architectures only to No from Yes.

The only downside is that when building a project for the first time or doing clean and build, it will compile OF twice, so that means OF will take twice as long to build.

I tried another approach where it was using the $(CURRENT_ARCH) macro to append the lib name i.e.: openFrameworksi386.a.
This worked fine for generating the library. But the app Xcode project was trying to link against the OF product as openFrameworksundefined_arch.a

If we didn't link against the product of the OF project but instead manually add the library to be linked and if we use the $(CURRENT_ARCH) macro in both the examples and the OF Xcode projects then it should work fine.

Maybe this is a better approach ( though more complicated ) than building universal libs?

[arturoc]

The only downside is that when building a project for the first time or doing clean and build, it will compile OF twice, so that means OF will take twice as long to build.

i do that in linux (for debug and release) and android (for arm7 and x86 in debug and release), it takes a while but it's just the first time and then you don't need to compile it again so it's not such a big deal.

i think building universal libs is pretty standard in osx and will save some headaches. ie: if someone compiles a project in 32 bit, opens another project and tries to compile in 64 it won't work because it won't compile the OF library for 64bit since it's open already somewhere else

[ofTheo]

okay - I'll make that change - its definitely the easiest and most stable fix.
if we get a lot of complaints we can look into other solutions :)