Xcode linker error: file too small for architecture x86_64

Question

I'm developing an application in Xcode.

When I try to build, this error comes up:

ld: in /Users/theodore/Library/Developer/Xcode/DerivedData/Tower-bkpdifuqssebjdgurzmtirbxejnn/Build/Intermediates/Tower.build/Debug/Tower.build/Objects-normal/x86_64/TWRAppDelegate.o, file too small for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Does anyone know what's wrong?

Solution 1

Stealing @martin-baulig's answer:

Try a full rebuild / clean. It's possible that the previous build has been abnormally aborted, leaving the TWRAppDelegate.o file corrupted or zero-size.

Solution 2

I usually add a space (could be any character for that matter) to the file in question, remove it and then save. Easier and quicker than a clean build.

Solution 3

To automatically fix this issue Build Script Phase can be added. Goto Xcode -> Your Project -> Your Target -> Build Phases -> + -> New Run Script Phase

Rename it to Xcode Link Fix and move it above Compile Sources phase. Paste this into script body:

# Legacy build system
legacy_dir=`dirname "${LD_DEPENDENCY_INFO_FILE}"`
if [ -d "${legacy_dir}" ]; then
    find "${legacy_dir}" -size 0 | while read -d $'\n' file; do
        rm "$file"
    done
fi

# New build system
if [ -d "${OBJECT_FILE_DIR_normal}" ]; then
    find "${OBJECT_FILE_DIR_normal}" -size 0 | while read -d $'\n' file; do
        rm "$file"
    done
fi

This script checks for object files with zero size and removes them so when compilation is done in next step it success.

You need to add this script for every app target if you have many.

This script takes ~0.1 second to run and saves you from full project rebuild.

Solution 4

rm -rf /Users/hostname/Library/Developer/Xcode/DerivedData

Solution 5

just remove this file by run cmd in your terminal app:

rm /Users/theodore/Library/Developer/Xcode/DerivedData/Tower-bkpdifuqssebjdgurzmtirbxejnn/Build/Intermediates/Tower.build/Debug/Tower.build/Objects-normal/x86_64/TWRAppDelegate.o

View more solutions

Comments

[Martin Baulig]

Try a full rebuild / clean. It's possible that the a previous build has been abnormally aborted, leaving the TWRAppDelegate.o file corrupted or zero-size.

[Ramy Al Zuhouri]

A little precisation: you do that with cmd+shift+k, if that doesn't work, go into the derived data folder and delete the folder named as your project.

[Nico]

@RamyAlZuhouri: There isn't any need to go Trashing build folders yourself anymore. Hold down Option and the Clean command (which is in the Product menu) changes to “Clean Build Folder…”, which does that for you.

[tbodt]

Martin Baulig's suggestion solved my problem. Thanks!

[tbodt]

@MartinBaulig If you post your suggestion as an answer, I'll upvote it and mark it as the accepted answer.

[tbodt]

@MartinBaulig CAN YOU HEAR ME?

[kidsid49]

@MartinBaulig : Thanks for letting me steal your comment. My cut-and-paste of it just got to 40 upvotes, and gave me the Guru silver badge. Go figure. :-)

[tbodt]

@PeterK. It's earning me the Nice Question silver badge :-)

[iosdude]

I started to often get this error for a third-party library written in Swift (PromiseKit). It used to work OK when I used the old version that was written in Objective-C. Maybe it's a bug in the Swift compiler?

[kidsid49]

@tbodt Woot! 100 upvotes!!

[Fernando Mazzon]

My project takes a while to build. You can get away with deleting just the 1-4 object files that get corrupted if you stop the build abnormally rather than everything.

[Accid Bright]

Your answer save me 10 minutes of rebuilding the project! Thanks

[Romano]

I solved it the same way, much faster than a full clean/build on my big project. Next time I will give @Anton Plebanovich 's solution a try, it could be an excellent way to automate this fix.

[Nike Kov]

It's genious! Need to have in every project.

[David Santiago]

A negative vote require an explanation, it worked for me and it could work for anyone else

[Groot]

Can just add this for others who find this answer. "Always Search User Path" has been deprecated as of Xcode 8.3 and from the documenation it also says "Disabling it is strongly recommended." (I.e. setting it to NO)

[Ting Yi Shih]

This answer should go to the top one!

[nrx]

Thanks, kind stranger! This is the correct answer. Cleaning the build folder is obvious and redundant.

[nrx]

Better use @grassyburrito's answer (just add a space or something to the corrupted file); cleaning the build folder is redundant and could waste a good deal of time

[kidsid49]

@nrx I tend to agree, but I've had it where several files were corrupted... and I didn't know until after several attempts at compiling. Depending on your project size, Martin's approach might be faster. And this answer was given two years before grassyburrito's :-)