HOWTO · Arduino

Fix Arduino Exit Status 1 by Reading the Actual Error

Arduino exit status 1 is a generic failure result. Find the diagnostic above it, fix common compile errors, and separate upload problems from build problems.

On this page

exit status 1 is the final result of a failed Arduino operation, not the reason it failed. Read the first error line above it, including the file and line number. If compilation failed, fix that diagnostic first. If compilation succeeds and upload fails, check the board, port, and upload path instead of changing working code.

Read the Useful Error Line

Compilation error: exit status 1 and ld returned 1 exit status are generic endings. The useful message is earlier in the console: commonly a path and an error such as expected ';', was not declared in this scope, or No such file or directory. Expand or copy the complete output; do not post only the final two lines. Arduino’s compilation guide documents these diagnostics.

Verify a Minimal Sketch

This exact sketch compiled with Arduino CLI 1.5.1, Arduino AVR Boards 1.8.8, and arduino:avr:uno:

void setup() {}

void loop() {}

Use arduino-cli compile --fqbn arduino:avr:uno <sketch-folder> for an Uno, replacing the FQBN with your board. If the minimal sketch fails too, reselect the board, install its platform through Boards Manager, and inspect the full output. A missing FQBN or platform is not a syntax error in your project.

Fix Common Compile Diagnostics

This exact failing sketch is missing the semicolon after Serial.begin(9600):

void setup() {
  Serial.begin(9600)
}

void loop() {}

The observed result is error: expected ';' before '}' token, followed by Error during build: exit status 1. Add the semicolon and compile again. Also check braces, identifier spelling, and variable scope; the reported line can be just after the original typo.

For fatal error: SomeLibrary.h: No such file or directory, verify the header spelling and #include form in the library documentation. Install the correct library through Sketch > Include Library > Manage Libraries. Copying an arbitrary .h file beside a sketch does not install its dependencies, and an installed library may not support the selected board. undefined reference to 'setup' or loop usually means a required function is missing or has the wrong capitalization.

Work from the first specific error.

Treat the console as a sequence rather than a single error. The IDE or CLI may print an initial compiler message, a few notes about where a symbol was declared, and then a generic summary. Start with the first line that names your sketch, an included file, or a library source file. Its line number is the first place to inspect. Messages farther down can be consequences: one missing closing brace can make later functions appear to be outside their expected scope, while a misspelled variable can lead to additional type or overload messages.

Do not fix every visible message at once. Make the smallest change that addresses the first specific diagnostic, compile again, then read the new first diagnostic if one remains. This prevents a guessed change from hiding the original problem. Save a copy of the complete output before changing anything when the issue is intermittent or when you need help from someone else. The board name, selected platform version, IDE or CLI version, and operating system are useful context; passwords, access tokens, and personal file paths are not.

Some messages identify a source file outside the sketch. A line in a library’s .cpp file does not automatically mean the library is defective. It can mean the sketch called the API with the wrong argument type, that two installed libraries provide the same header, or that the selected board is unsupported. Read the lines immediately above the library path to see which include was chosen and which type or symbol failed. Use the library documentation to confirm its supported boards and its required includes instead of downloading a random replacement from an unverified site.

Check the board platform before changing project code.

The selected board determines the compiler settings, core libraries, and build target. For an Arduino Uno, the FQBN in the example is arduino:avr:uno; another board needs its own FQBN and installed platform. In the IDE, select the actual board under Tools > Board. In Arduino CLI, list installed cores and use the FQBN reported for the target. A missing platform, an invalid FQBN, or a platform installation problem can stop compilation before the sketch itself is evaluated.

This is different from choosing a serial port. The port becomes important when uploading to physical hardware, but a normal compilation can run without a connected board. If a minimal sketch compiles for the intended FQBN and the project does not, the environment is sufficiently set up to focus on the project’s first diagnostic. If the minimal sketch fails, resolve the platform or board selection first. Reinstalling every library or rewriting the sketch cannot repair a missing board core.

After changing board settings, compile again and compare the first useful message. Avoid treating a successful upload to a different board as proof that the original board setup is correct. Differences in processor architecture, core version, available libraries, and pin definitions can create a different build result. Record the selected board and platform version when reporting an issue so that another person can reproduce the same toolchain.

Recognize common diagnostic categories.

Syntax diagnostics are usually local: a missing semicolon, quote, parenthesis, brace, or comma. Read a few lines before the reported location, especially when the message points at a closing delimiter. Name and scope diagnostics such as was not declared in this scope mean the compiler cannot see an identifier at that point. Check capitalization, declaration order, spelling, and whether a variable was declared inside a different function or block. Arduino sketches are transformed before compilation, so keeping function declarations and definitions clear makes these messages easier to interpret.

Header diagnostics identify an include that the compiler cannot locate. First confirm the exact spelling and case from the library’s own documentation. Then use Library Manager to install the supported library, restart or rebuild if the tool asks, and compile again. Do not assume that a similarly named library is interchangeable. A library may use the same header name but target another architecture, or it may require a companion dependency. When multiple candidates are installed, the detailed output can reveal which one the build selected.

Linker diagnostics occur after source files have compiled. undefined reference means a declaration was found but the corresponding implementation was not linked into the build. For the Arduino entry points, confirm that both void setup() and void loop() exist with exactly that spelling and return type. For a library function, check whether the library needs a particular board package, a source file, or a configuration option. The final exit status 1 does not distinguish a compiler error from a linker error; the earlier diagnostic does.

Use a repeatable recovery checklist.

First, copy the complete output and identify whether the operation was Verify/compile or Upload. Second, locate the first specific diagnostic and make one targeted correction. Third, compile the minimal sketch for the same board FQBN if the report suggests a platform or configuration problem. Fourth, when a library is involved, check its header spelling, installation, dependencies, and board support through its documentation and Library Manager. Fifth, compile again before moving on to another reported message.

If the code builds, stop using compilation advice to diagnose a failed upload. Recheck the selected board and port, disconnect and reconnect the board if appropriate, and make sure no serial monitor, terminal, or another IDE instance has the port open. Some boards also need a particular processor selection or bootloader setting. These are transport and target-configuration questions, not evidence that a semicolon or include is wrong. Arduino’s official guidance separates compilation and upload troubleshooting for that reason.

When escalating the problem, make the report reproducible: include the first error and surrounding lines, the complete console output, a minimal sketch when possible, the exact board and platform version, and whether Verify succeeds. State what you already tried. This gives a helper evidence rather than a vague final status line, and it protects you from repeatedly applying unrelated fixes.

Treat Upload Failures Separately

If Verify succeeds but upload ends in status 1, it is not a syntax failure. Confirm the board and port, close other serial-monitor sessions, reconnect the board, and check processor or bootloader options when applicable. Arduino’s upload guide covers that branch. A compile fixture cannot test upload behavior without a physical board and serial port.

When requesting help, provide full console output, IDE and board-package versions, board, operating system, and a minimal reproducing sketch. Remove passwords, tokens, and private paths first.