I do my mozilla-central builds on a remote machine which is several times faster than my own laptop. The remote machine (I call it Tibet) is a Fedora 16 on which I setup a simple ssh server for my use. I made a new user account which I would use remotely or locally, depending on whether I was around the machine or not.
So one fine day, I start coding locally, and after some typing tried to build what I had. Upon passing a make command however, I recieved the following error:
gcc -o host_nsinstall.o -c -pedantic -Wall -W -Wno-unused -Wpointer-arith -Wdeclaration-after-statement -Wcast-align -W -Wno-long-long -fno-strict-aliasing -pthread -ffunction-sections -fdata-sections -pipe -DDEBUG -D_DEBUG -DTRACING -g -fno-omit-frame-pointer -DXP_UNIX -DUNICODE -D_UNICODE -I/home/abhishek/Desktop/mozilla-central-abhishek/config -I. -I../dist/include -I../dist/include/nsprpub -I/home/abhishek/Desktop/mozilla-central-abhishek/obj-i686-pc-linux-gnu/dist/include/nspr -I/home/abhishek/Desktop/mozilla-central-abhishek/obj-i686-pc-linux-gnu/dist/include/nss -I/home/abhishek/Desktop/mozilla-central-abhishek/obj-i686-pc-linux-gnu/dist/include/nspr gcc: fatal error: no input files compilation terminated.
The problem seemed to be in obj-i686-pc-linux-gnu, the ‘build to’ directory. Simple enough, remove it and try again. The previous build must have been incomplete and host_nsinstall.o must not be fully formed. After doing that, I tried again and succeed and decided to leave for home.
Next day, I logged into Tibet from home, made some changes and tried another build.
gcc: fatal error: no input files compilation terminated.
But this time around, even removing the object directory wouldn’t help. I couldn’t understand why. Anyway, after much agony, someone on IRC forwared me to this page.
An old bug from 2004, but still alive. The problem, as the author describes occurs when the login shell is not /bin/bash. On F16, when you create a new user account through the ‘Users and Groups’ console, the default shell assigned to a new user is dash.
As the author of that bug suggests though, forcing the shell to be /bin/bash in the config solves the problem.
So there you have it, two problems with the same prognosis, but different solutions.