I was trying to compile a third party Rust crate today on a Debian box and I was getting a weird error I’d never seen:
= note: cc: fatal error: cannot read spec file './specs': Is a directory
compilation terminated.
I’ve done a bunch of embedded C stuff in the past so I knew what a specs file was—but why couldn’t gcc open its specs file? The first clue was that this particular crate had a directory at its top level called “specs”. I moved it away and the error went away. Ok. But why is gcc looking for a specs file in my cwd??
Rust printed out the linker command it was using to invoke gcc with so I could look through that but there was nothing referencing a spec file there.
I figured it might be something set up incorrectly on my local machine but there’s practically no documentation about where gcc looks for specs files. I ended up downloading the gcc source (thank heavens for apt source!) and grepping it for “cannot read spec file”, which lead me to the load_specs() function in gcc/gcc.c. Ok. So I poked around that file, following the thread of function calls around and just sort of looking for anything. I eventually noticed startfile_prefixes which appeared to be where they searched for specs. Searching around the file led me to a section where it looped over LIBRARY_PATH and added each component to startfile_prefixes. This stuck out to be because I had LIBRARY_PATH set in my env.
I looked at it more closely and noticed it was
LIBRARY_PATH=/usr/local/lib:
Hmm. Why does it have a stray : on the end? Maybe that’s it. I tested it with:
LIBRARY_PATH=/usr/local/lib cargo build
And everything built just fine! Yay!
So it was my fault after all… Sigh. I checked my .bashrc and found a bug in one of my path construction functions which was putting the extra : on the end. Then I spent some time relearning a bunch of excruciating shell details and getting everything fixed. 🙂