Linker warnings building with 1.0.2 framework ("unable to open object file") #460
Comments
|
This has been discussed on the mailing list — I can go look up the threads, but IIRC the warnings happen while generating the debugging symbols for the app, and changing the style of symbols (using a dSYM? Not using a dSYM?) makes the warnings go away. |
|
Here's the mailing list thread.
It was also noted that doing so will interfere with using the Crashlytics service. |
|
I've tried changing CBL's build settings, trying both debug information formats and stripping options, but haven't been able to make the warnings go away. I've just posted a question to Apple's xcode-users mailing list. |
snej
changed the title
|
Thank you for looking into it, @snej. |
|
Just wanted to +1 this and add my own info. I encountered it trying to build the ToDoLite app for iOS using the enterprise version as well. warning: (i386) /Users/jenkins/jenkins/workspace/build_cblite_ios_102-enterprise/couchbase-lite-ios/build/CouchbaseLite.build/Release-iphonesimulator/CBL iOS library.build/Objects-normal/i386/CBLChangeTracker_Tests.o unable to open object file |
|
I think that I'm going to back out the build-setting change that introduced this problem. |
|
Just wanted to comment that I observed this issue right out of the gate by simply adding 1.0.3 to my project using Cocoapods. |
|
Is there a fix for this when building 1.0.3 from Cocoapods? I've tried setting The warnings are gone if I set this on my application's target, but I'd like to build with symbols enabled. I can't see any recent commits that would fix this issue in |
|
@snej - Do you have any idea when a release will be made with a fix for this? |
|
This is generating 139 warnings when using 1.0.3 in xCode 6.1 |
|
Have you tried set |
|
We want debugging symbols, though. Without them it's much harder to interpret stack traces, which makes debugging a pain. |
|
You mean you want or your want your users have debugging symbols? You can have 2 schemes, let us say |
|
I think by "users" you mean "developers", right? We want developers to have our debugging symbols in their apps, so that when their app crashes the backtrace has meaningful information in it. So the library we build, that they link against, needs to have debugging symbols in it. I'm not sure you're understanding that what we produce is a static library, not an app or an OS X style dylib framework. |
|
What's the current recommend fix for this issue. Why it's closed. Should my team wait until 1.1.0? |
|
The issue was fixed in fe092a9, but that was not included in v1.0.4 which is waiting for an official release either. To get the fix now, you will need to build the framework from the master branch. Sorry for the inconvenience. |
|
Thanks so much. We are using the master now. Long Sun On Monday, 9 February 2015 at 2:06 pm, Pasin Suriyentrakorn wrote:
|
|
@spritesun The master branch is currently in an unstable state, as major features just got merged into it. I wouldn't recommend switching to it right now. Is there a reason the linker warnings are a serious issue for you? I know they're annoying, but they should not be breaking your build. |
|
If you really want the fix now, I would recommend updating to commit aeb996a (tagged |
Good news: this will get rid of the 100+ link warnings when building an iOS app using Couchbase Lite. Bad news: It reopens couchbase#413, the problem that internal symbols are exposed in the library, which can cause duplicate-symbol errors when building an app using libraries (like yajl) that CBL also uses. Fixes couchbase#460 (cherry picked from commit fe092a9)
The text was updated successfully, but these errors were encountered: