libXcodeDebuggerSupport.dylib is missing in iOS 4.2.1 development SDK

21,297

Solution 1

What I just did to solve this problem was:

cd /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.2.1 (8C148)/Symbols

and created the symlink was missing:

ln -s ../../4.2\ \(8C134\)/Symbols/Developer/ Developer

It solves my problem.

Solution 2

If you do not have anything to lose, just dump the whole Developer folder (or Developer4.2 or however you call it). Reinstall from scratch with the official release of iOS 4.2 SDK - "Xcode 3.2.5 and iOS SDK 4.2". I did that and found everything gets installed under 4.2 (8C134) only, and does not use 4.2.1 at all.

Solution 3

I do not have enough points to comment to the accepted answer. Trinca's solution works for me.

Only one addition though: I got a permission denied in Xterm when I tried to execute the ln command.

just had to enter

sudo xterm and enter my admin password for the system and repeat the process in the new terminal.

I am wondering how many people out there are re-installing Xcode because of this issue. It is definitely a huge waste of time, if people went ahead with re-installation without checking for a better solution. Apple has to keep enough reviewers for sdk runtime checks, and not just for our apps :).

Share:
21,297
Kalle
Author by

Kalle

I'm a Swedish software developer working for Digital Garage in Tokyo, Japan.

Updated on May 19, 2020

Comments

  • Kalle
    Kalle about 4 years

    Note: getting this on Xcode 4.3.2? Check out the answer to this question.

    Note: creating a symbolic link to use the 4.2 lib seems to work fine

    cd /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.2.1\ \(8C148\)/Symbols/
    sudo ln -s ../../4.2\ \(8C134\)/Symbols/Developer
    

    After upgrading from 4.2.0 (beta, I believe) to 4.2.1, the libXcodeDebuggerSupport.dylib file is missing, which results in:

    warning: Unable to read symbols for /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.2.1 (8C148)/Symbols/Developer/usr/lib/libXcodeDebuggerSupport.dylib (file not found).
    

    which I guess isn't good. Looking at the directory in question I note:

    .../DeviceSupport/4.2 (8C134)/Symbols/Developer/usr/lib/libXcodeDebuggerSupport.dylib
    

    but

    .../DeviceSupport/4.2.1 (8C148)/Symbols/System/
    .../DeviceSupport/4.2.1 (8C148)/Symbols/usr/
    

    the above two dirs make up all the content in the 4.2.1 folder. No "Developer" folder. Checking the /usr/ dir there, I find no libXcodeDebuggerSupport.dylib file in the lib dir either, so ln -s'ing isn't an option.

    Worth mentioning: after the upgrade, I plugged the iPad in and had to click "Use for development" in Xcode organizer. Doing so, I got a message about symbols missing for that version, and Xcode proceeded to generate such, then failed. I restored the iPad and did "Use for development" again, and nothing about missing symbols appeared...

    Update: deletion of /Developer and reinstallation of Xcode from scratch does not fix this issue.

    Update 2: I just realized that after the reinstall of Xcode,

    .../DeviceSupport/4.2 (8C134)/Symbols
    

    is now a symbolic link,

    lrwxr-xr-x  1 root  admin        36 Dec  3 17:17 Symbols -> ../../Developer/SDKs/iPhoneOS4.2.sdk
    

    And the directory in question has the appropriate files. Maybe this is simply a matter of linking the 4.2.1 dir in the same fashion? I'll try that and see if Xcode freaks out. If someone who has this file could provide a md5 sum that would be splendid. This is what it says for me:

    $ md5 /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.2\ \(8C134\)/Symbols/Developer/usr/lib/libXcodeDebuggerSupport.dylib 
    MD5 (/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.2 (8C134)/Symbols/Developer/usr/lib/libXcodeDebuggerSupport.dylib) 
        = 08f93a0a2e3b03feaae732691f112688
    

    If the MD5 sum is identical to the output of

    $ md5 /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.2.1\ \(8C148\)/Symbols/Developer/usr/lib/libXcodeDebuggerSupport.dylib 
    

    then we're all set.