Cedar, Cedar, who's got the Cedar? (Multiple versions of library in project)

[Joshua Marker]

After recently upgrading Cedar and PivotalCoreKit both to HEAD of master, we started getting link errors with missing symbols, to wit:

Undefined symbols for architecture i386:

  "Cedar::Doubles::StubbedMethod::raise_for_multiple_return_values() const", referenced from:

. . . . 

. . . etc.

We use Cedar as a submodule precisely so we can get the latest goodies without waiting for releases.

Now, PivotalCoreKit also uses Cedar as a submodule, but a slightly older version. 

I checked the commits between the version of Cedar employed in PCK and HEAD:

git grep raise_for_multiple_return_values $(git rev-list 9914b2d..4a80e9d)

and found that, indeed, there were new calls to raise_for_. . . . .etc. 

Setting my project’s Cedar submodule back to the same version as PCK’s made linking work correctly.

What I think is going on here is that Xcode’s implicit dependency tools are building Cedar for PCK and then being content with that, older, version later on when my test suite needs it as well. 

Unlike Xcode, I am not content with this. Since Cedar is a project in my workspace, I can’t simply tell it that my particular version of Cedar is a dependency, and I am thrown upon the mercies of Xcode’s dependency resolution system.

Can anyone suggest a way to get the version of Cedar I want that doesn’t involve forking PCK? 

[Brian Croom]

It sounds like the compiler is finding the headers from your Cedar submodule, but the linker is finding the lib from PCK's copy of Cedar. I'd suggest checking out your Library Search Paths build setting to make sure it's not looking in the wrong spot.

Are you using a Spec Suite or a Testing Bundle? Linking against the static lib or the framework? Also, have you tried cleaning your build directory? 

--
You received this message because you are subscribed to the Google Groups "Cedar Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cedar-discus...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Brian Croom
Agile Engineer
bcr...@pivotallabs.com
416.455.5495

[Joshua Marker]

Thanks Brian.

The library (a static library) is created in the BUILT_PRODUCTS_DIR by both/either version of Cedar. This is the search path used (via $inherited) in the build settings. This is the correct path; the issue is (I think) that the dependency is satisfied by the earlier version and the later version thus does not get built. Were it to do so, it would be built to the same location. This is why I said “. . . . without requiring me to fork” - the only way to change where the Cedar product will be built. 

This is with a spec suite; the issue would be present with the bundle, as well, though, for the same reason. 

So the question becomes how to specify that I wish to use a specific version of a static library, or rather, that a specific source be built. Any suggestions?

[Brian Croom]

I would be interested in seeing the full build log produced when building the target after a clean. At that point it should be rebuilding the Cedar static lib from source, and it should be clear from the file paths in that log which Cedar is being used.

I just spent a few minutes trying to replicate your situation. I was unable to get the failure you are seeing, however I can understand how the problem could arise, since Xcode doesn't provide a good way to distinguish between the different copies of Cedar when configuring the target. You might try going to your suite's Build Phases tab, removing Cedar-StaticLib from both the Target Dependencies and Link Binary With Libraries sections, and then adding it back to each one. Maybe that will convince Xcode to use the correct lib.

[Sam Coward]

This does seem odd.  I have a few projects running HEAD on PCK and Cedar as well without this issue.  What's peculiar is PCK's Cedar shouldn't even be built unless you're running PCK's specs; it's not a dependency of the PCK libraries, only their tests.

Brian's suggestion seems sound.  You can even try dragging the libCedar-staticLib.a from under the Products group in the correct version of Cedar in the project browser into the "Link Binary With Libraries" section.  Beyond that, I'd also recommend digging into the full build output.

A crude temporary workaround might be to not initialize the Cedar submodule under PCK.  They only need to be present to run PCK's specs; you can link against the PCK libraries fine without it.

[Joshua Marker]

That's especially interesting Sam. I do drag the lib out of the products folder in the hopes that Xcode will be swayed to do my bidding. No luck until I downgrade my cedar.

When you have a cedar and a PCK at HEAD is your cedar a sub project or are you using workspaces? This is in a workspace and I wonder whether I am a victim of this less precise new mechanism. 

I had a release today but I will get the build logs as you suggested, Brian. I must admit I rounded toward the assumption since I have so little trust in xcode's dependency resolution and the downgrade seemed to corroborate but I should verify it. I may also try not initializing PCKs cedar. 

[Sam Coward]

I wasn't using a workspace, so that might be making the difference.

—
Sam

[Andrew Kitchen]

Hey Joshua,

I think the quickest solution is going to be not cloning PCK's
submodules. You can undo this with git submodule deinit [...]

I have run into this with Xcode 5 as well; sadly I haven't had
bandwidth to look into it much.

Please let us know if you come up with a more sustainable solution --
a pull request would be the ultimate. However you will need to fork
PCK to do that :)

Andrew

On Wed, Apr 16, 2014 at 10:12 PM, Sam Coward <sco...@pivotallabs.com> wrote:
> I wasn't using a workspace, so that might be making the difference.

> --

[edtr...@gmail.com]

Hi Joshua,

Did you ever get a resolution to this issue?  I'm also having the same problem.  We were setup with Cedar 0.9.0 and use PivotalCoreKit as well using Xcode 5.0.2 for our project.  Recently I tried to update to the latest version of Cedar 0.9.6 with Xcode 5.1.1 and have run into 

Undefined symbols for architecture i386:

  "_OBJC_CLASS_$_CDRSpecHelper", referenced from:

      ...

  "CDR_fake_for(signed char, objc_class*, ...)", referenced from:

      ...

  "CDR_fake_for(signed char, Protocol*, ...)", referenced from:

      ...

  "Cedar::Doubles::Arguments::anything", referenced from:

      ...

  "Cedar::Doubles::operator,(id<CedarDouble>, Cedar::Doubles::StubbedMethod const&)", referenced from:

      ...

  "Cedar::Matchers::RaiseException::RaiseException(NSObject*, objc_class*, bool, NSString*, NSString*)", referenced from:

      ...

  "Cedar::Doubles::StubbedMethod::raise_for_multiple_return_values() const", referenced from:

      ...

Regards,

Ed

[Joshua Marker]

I did. The problem was exactly as hypothesized. Using workspaces, it’s (apparently?) impossible to control the order of object file loading.

So I just de-inited the version in PCK, since, as Sam said, it’s not used except for running the tests.

If anyone can tell me how to change the load order, I’d be delighted to hear it. It appeared to vary, though, because sometimes it would work correctly, which leads me to conclude it’s unspecified. 

[Sam Coward]

There's been a fair amount of work lately to get Cedar and PCK working better with CocoaPods.  We've had a few projects here in NY starting to use this approach.

The installation page on the Cedar GitHub wiki now has a CocoaPods section.

—
Sam

[Joshua Marker]

The correct answer, by the way, for anyone encountering this is to `git deinit` PCK's Cedar. Xcode will occasionally re-init it and add the LIBRARY_SEARCH_PATH. Be vigilant.