Error: Unable to open include file

[IamToBlame]

Hello everyone,
Compiling programs using NASM (3.02) under Windows 11 produces no errors while under Linux Mint 22.3 (Cinnamon) using NASM version 3.02rc13 compiled on Aug 15 2026 generates errors as per title and yet all files do exist and each file's path is hardwired correctly, I'm at my wits' end trying to figure out the mystery, would appreciate any kind of help and direction that might solve this issue, thank you.

[MLuc24]

Worth knowing exactly what NASM tries before blaming the paths, because the search is narrower than people usually assume. inc_fopen_search starts with an empty prefix and then walks the -i list:

ip = omode & INC_EXACT ? NULL : strlist_head(ipath_list);

while (1) {
    sp = nasm_catfile(prefix, file);
    ...
    prefix = ip->str;
    ip = ip->next;
}

So it tries the name exactly as written — resolved against the current working directory, not against the directory of the file doing the %include — and then each -i path as a prefix. There's no "look next to the including file" step at any point.

Given it works on Windows and not on Linux with the same sources, three things are worth checking in this order.

Case is the usual one. Linux filesystems are case-sensitive and NTFS effectively isn't, so %include "Macros.inc" finds macros.inc on Windows and finds nothing on Linux. Everything looks correct in the editor because the name is right, just not in the right case. ls the directory and compare character by character rather than trusting your eye.

Backslashes are the next suspect, and they bite hardest when paths are hardwired. On Linux \ isn't a separator, it's an ordinary character in a filename, so %include "inc\defs.inc" is asking for a single file literally named inc\defs.inc in the current directory. That fails with exactly this message and looks fine on Windows. Forward slashes work on both, so they're the portable choice.

Third, if the paths are relative rather than absolute, check where you're invoking nasm from. Since resolution is against the CWD and never the source file's directory, building from the project root versus from inside the source directory gives different results, and your Windows build may simply be run from a different place — by an IDE, say, rather than by hand.

If none of those are it, nasm -M will print the dependencies it resolves and is usually quicker than guessing — the file it can't find will be conspicuous by its absence.

[IamToBlame]

Thanks @MLuc24,
I went through the list of errors with eagle eyes so to speak (thanks for github forum being down at around 4am my time :)), anyway... migrating from windows I found that the spelling of each of those files differed by one letter (should be in uppercase) as Linux world is case sensitive. Problem solved and thanks again for your attention.