I started getting this strange message when compiling for my iPhone:

ldr 12-bit displacement out of range

Eventually I found that quitting XCode, deleting the build folder in the project then reopening XCode and re-building made everything work again.

Just putting here in case anyone else has similar issues!

UPDATE: Anyone else with this problem, please file a bug report with Apple (http://bugreport.apple.com/) because if lots of people file a bug then hopefully they’ll do something about it.

Share and Enjoy:
  • Digg
  • del.icio.us
  • Facebook
  • Google Bookmarks
  • LinkedIn
  • Twitter

18 Responses to “ldr 12-bit displacement out of range”

  1. jbishop says:

    This happens occasionally in my project as well; albeit only with SDK 3.1+. Deleting and rebuilding doesn’t do it for me. I usually backtrace my steps, then retrace them, building at every step, and about 1/2 the time the link error goes away by the time I’ve reconstructed my code. The other half, I move on, and the new arrangement of bits and bytes seems to alleviate the problem for a while… very weird.

  2. Hmm that is interesting. Out of interest, which frameworks are you linking against? I’d like to see if we can narrow this down a bit. Also, what does the whole error say for you, including which framework/library the linked error is in?

  3. Ben Anderman says:

    This happened to me, and I know exactly what I changed: I added AVFoundation.framework to the project. I’m using iPhone SDK 3.1.2. Here’s my error:
    ld: ldr 12-bit displacement out of range (4452 max +/-4096) in _AudioComponentFindNext$stub in _AudioComponentFindNext$stub from /Users/ben/projects/frogatto/iPhone/Frogatto/build/Release-iphoneos/Frogatto.app/Frogatto

  4. That’s really interesting because that’s the exact place I am having the problem in as well… It doesn’t happen if I compile for armv7 only though – does that also “fix” things for you? (Well, it’s not really a fix because that would cut out all 3G iPhone users).

  5. Raj Pawan says:

    We faced this problem recently in iPhone SDK 3.1 and could solve it by re-ordering the libraries in “Link Binary with Libraries” in the build phase of target. It would build successfully without any changes in iPhone SDK 3.0 though.

    Hope this helps someone out there.

  6. Hmm that’s interesting Raj. I’d had some success with reordering but then still came across the problem even after reordering as much as I could try. It’s a really annoying bug!

  7. Anyone who has this problem and finds this post, please can you list all things which your app is being linked against? I want to try to get to the bottom of what exactly is causing this problem.

  8. Raj Pawan says:

    Ya, an annoying bug, took lot of our time to find out, but then re-ordering worked for us. We used ARM6 to build our static libraries. in which one of them had to be re-ordered to get rid of the problem.

  9. Winston Yang says:

    I’m also receiving the same errors. My libraries that I’m linking in is:
    -lMagickWand -lMagickCore -lMagick++ -lpthread -ljpeg -lpng -lz -lm -ltiff.
    I am trying the reordering strategy. For me, the same experience as above, Device 3.0 build+deploy works.

  10. Winston, what about frameworks? Which ones are you linking against?

  11. Ken says:

    Has anyone found a solution yet? I am also having this problem. It started when I added the libiSlide.a library, which is an advertisement fetching library (don’t hate me!).

    If I remove the library the error goes away. But I need the library to finish the project.

    BTW this same library links without error in my other projects so I know it isn’t that library that is the problem.

    I’ve also rearranged the link order of my other libraries and the error still occurs.

    I began adding other libraries that I didn’t need to see what would happen. I managed to get it to link correctly once with some random unneeded library, but the error just came back later.

    Any help would be appreciated!

  12. It’s still a major problem for me and happens when I’m linking against too many things / too large libraries. It only happens when building for armv6 and it’s mightily annoying!

  13. yasirr says:

    ld: ldr 12-bit displacement out of range (4260 max +/-4096) in _AudioFileCreateWithURL$stub in _AudioFileCreateWithURL$stub

    i am facing similar kind of problem any solution or suggestion ? thanks in advance

    i have tried every option mentioned by @all above but hardly found a kind success build i am thinking if there is a link reordering solution for static libraries we are using …

  14. @yasirr – No real fix found yet AFAIK. Please file a bug report at http://bugreport.apple.com/ – I have and they replied immediately but no fix found yet. If everyone files a bug then maybe they’ll fix it!

  15. yasirr says:

    thnx for a very fine prompt reply Galloway. can we discuss what we both are basically want to do and this public forum i am not familiar with her policy .. ok i just start if admin allow me i will proceed, i am on mencoder’s x264 .a files to produce a video out of images stream, my problem is when i link .a files which are pretty dependent to each other so linking order i can predict is what causing all mess in my project

  16. @yasirr – I don’t really want to go into depth about what I’m trying to link against – it’s largely irrelevant anyway.

    I really suggest that everyone files a bug report and then maybe things will happen Apple’s end to fix it.

  17. Michael Toy says:

    I don’t have control over the link line, since I am using a CMake generated XCode project, but “man ld” revealed this, which solved the problem for me.

    -no_order_inits
    When the -order_file option is not used, the linker lays out functions in object file order and it moves all initializer rou-
    tines to the start of the __text section and terminator routines to the end. Use this option to disable the automatic re-
    arrangement of initializers and terminators.

  18. Adam Freeman says:

    Whatever anybody wants to say about Microsoft at least they do not have weird quirky bugs in their sdk’s. When you write code that uses Microsoft SDK’s at least you know it is not going to do totally weird things. Apple’s SDK’s are laden with their own bugs. Hey apple fix your own bugs!!

Leave a Reply