oF static lib product named differently when built in Xcode than from make

I've run into this a few times and been confused but when building the oF static lib, Xcode uses a different build product name than when building from make 😦

Xcode: libs/openFrameworksCompiled/lib/osx/openFrameworksDebug.a
make: libs/openFrameworksCompiled/lib/osx/libopenFrameworksDebug.a

Should these product names be the same?

[bilderbuchi]

afaik, this is because of some MacOS (XCode?) quirk which acts up if your libraries begin with lib.... I'll close this, but if I'm wrong we can just reopen.

That would be most unusual if so and I can't say I've ever had a problem linking to static or dynamic libs based on the filename prefix. Off the top of my head I know that Cinder builds it's static libraries with a lib prefix…

[bilderbuchi]

yeah I know, it's in other libraries, too, e.g. checkout out the poco directories. @arturoc @bakercp @openframeworks/macos can you give a more precise explanation?

[bakercp]

I have no explanation and would love to fix this. So far it is based on reports from @ofTheo.

Here is a recent discussion:

openframeworks/apothecary#28

Perhaps @ofTheo could give us the lowdown?

From @ofTheo's comment, it almost sounds like a LIBRARY_SEARCH_PATH priority/ordering issue. Either way though, in this specific case I don't imagine the system will provide it's own libopenFrameworks.a right? 😉

[ofTheo]

I think libopenFrameworks.a is fine.

Basically the issue is that in Xcode if you have a library included as libopencv.a Xcode changes it to -lopencv in the project settings. Then if you have a dynamic lib of OpenCV installed in /usr/local/lib Xcode decides to link to that one instead of the one you explicitly provided. This causes problems when sharing an executable because the linker most likely won't find the dynamic library when running on another machine.

I have seen this issue with libusb as well.

While it wouldn't be difficult to make the change in the Xcode project and projectGenerator/examples, the hangup might be in existing user-projects, as they'd be linking against a now missing static library openFrameworks.a. I still think we should use the lib-prefixed filename but I just wanted to mention the user-action required when this is made.