Home/ Questions/Q 7041567
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-28T02:03:41+00:00

I’m trying to produce gcd a files from an iOS Xcode 4.2 (4D199) project

  • 0

I’m trying to produce gcd a files from an iOS Xcode 4.2 (4D199) project called CocoaTouchHax on Lion and I’m having incredible trouble. I followed the steps here and I went as far as trying to build llvm/clang from source following steps here. However I continue to get this error:

Library not loaded: @executable_path/../lib/libprofile_rt.dylib

Where am I going wrong? I’ve tried to use the install_name_tool to fix the executable path to no avail. Am I over analyzing something? Am I missing something simple? I put this in as a “Run Script” phase prior to linking to ensure I’ve updated the @executable path and I use tool to examine the file after and the name is updated:

install_name_tool -id @executable_path/Users/cliff/dev/CocoaTouchHax/build/CocoaTouchHax/Build/Products/Debug-iphonesimulator/lib/libprofile_rt.dylib build/CocoaTouchHax/Build/Products/Debug-iphonesimulator/lib/libprofile_rt.dylib

What am I doing wrong? Help!

Update
Merely adding lib profile_rt.dylib crashes my test run immediately giving the following error when anything is run:
@executable_path/../lib/libprofile_rt.dylib
So I am certain that something needs to happen or something needs to be done to the lib profile_rt.dylib prior to execution.

Another Update I tried creating a sum link to
/Developer/usr/lib
under /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator5.0.sdk/Developer/usr
Which I believe is part of the base the path forming the current working directory when test runs. (Assuming it runs from the bin folder there.) This would, in theory, complete the relative lookup path of ../lib/libprofile_rt.dylib from that base path but it didn’t work. I’ve tried running the install_name_tool command prior to copying the dylib in place but I still get this error:

Library not loaded: @executable_path/../lib/libprofile_rt.dylib

I don’t know what I’m doing wrong. I somehow did manage to get test coverage files to emit using some combination of the above but I was not paying close enough attention and cannot reproduce the occurance. I know this can work, I just need a little more help figuring out how.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    On Lion you can symlink the dylib into /usr/lib to avoid that error

    sudo ln -s /Developer/usr/lib/libprofile_rt.dylib /usr/lib/libprofile_rt.dylib

    I cant guarantee that that wont bust something the future however. Remember that you have done it.

    Create a new configuration called “Coverage” (or whatever).

    In the Coverage config variant you have created go to Build Settings and…

    • Add -fprofile-arcs and -ftest-coverage to Other C Flags
    • Switch on Generate Test Coverage Files
    • Switch on Instrument Program Flow
    • In Other Linker flags add -lprofile_rt

    The reason to do it this way with a config is that you can keep your normal build untouched. Also only works on Simulator. So dont try running this on device.

    And from http://mattrajca.com/post/8749868513/llvm-code-coverage-and-xcode-4

    Finally, open up the Intermediates/$TARGET.build/$CONFIG/$TARGET.build/Objects-normal/$ARCH subfolder. Inside, you’ll find the aforementioned gcda and gcov files

    You can open that folder with CoverStory.

    Note that coverage is not cumulative (unlike Coverity) so each run starts afresh. There might be a way to change that.

    • 0