2008-10-19 143 views
2

嘗試編譯使用GCC的C程序時,出現完全bizzare錯誤。以下是我正在使用的批處理文件:Windows XP上的GCC編譯器錯誤

echo Now compiling, assembling, and linking the core: 
nasm -f aout -o start.o start.asm 

gcc -Wall -O -fstrength-reduce -fomit-frame-pointer -finline-functions -nostdinc -fno-builtin -I./include -c -o consoleio.o consoleio.c 
gcc -Wall -O -fstrength-reduce -fomit-frame-pointer -finline-functions -nostdinc -fno-builtin -I./include -c -o core.o core.c 
gcc -Wall -O -fstrength-reduce -fomit-frame-pointer -finline-functions -nostdinc -fno-builtin -I./include -c -o system.o system.c 

ld -T link.ld -o core.bin start.o core.o system.o consoleio.o 
echo Done! 

concat.py 

pause 

以下是我在嘗試運行此代碼時收到的錯誤消息。所有的文件都在同一目錄中,是PATH變量設置正確:現在

C:\Simple\core>build.bat 

C:\Simple\core>echo Now compiling, assembling, and linking the core: 
Now compiling, assembling, and linking the core: 

C:\Simple\core>nasm -f aout -o start.o start.asm 

C:\Simple\core>gcc -Wall -O -fstrength-reduce -fomit-frame-pointer -finline-func 
tions -nostdinc -fno-builtin -I./include -c -o consoleio.o consoleio.c 
The system cannot execute the specified program. 

C:\Simple\core>gcc -Wall -O -fstrength-reduce -fomit-frame-pointer -finline-func 
tions -nostdinc -fno-builtin -I./include -c -o core.o core.c 

C:\Simple\core>gcc -Wall -O -fstrength-reduce -fomit-frame-pointer -finline-func 
tions -nostdinc -fno-builtin -I./include -c -o system.o system.c 
The system cannot execute the specified program. 

C:\Simple\core>ld -T link.ld -o core.bin start.o core.o system.o consoleio.o 
c:/djgpp/bin/ld.exe: system.o: No such file: No such file or directory (ENOENT) 

C:\Simple\core>echo Done! 
Done! 

C:\Simple\core>concat.py 
Traceback (most recent call last): 
    File "C:\Simple\core\concat.py", line 12, in <module> 
    with open("core.bin", "rb") as core: 
IOError: [Errno 2] No such file or directory: 'core.bin' 

,有趣的是gcc的命令,這是我遇到的問題。 (其他問題似乎是從這個級聯。)編譯core.c時,GCC命令工作得很好,並且按預期生成一個.o文件。當試圖編譯system.c或consoleio.c時,GCC失敗,但以一種非常意外的方式:看起來好像windows不能運行程序。這讓我感覺到。我已經嘗試了許多東西,包括在窗口外自己運行這些命令。關於core.c的一些東西很特別,我無法弄清楚它們有什麼不同。我從字面上複製了該行,並更改了文件名以創建其他兩行失敗的行。

因此,總之,幫助。我在Windows XP上使用DJGPP和GCC,並在最後使用python腳本將所有內容連接在一起。 (當項目是單個源文件時,這一切都奏效,但試圖將文件分割成單獨的文件導致了這個奇怪的錯誤。)

謝謝。

PS:是的,我們使用批處理文件,我知道這讓你們有些畏縮。不過,如果可能的話,我真的很想理解這個錯誤,然後再轉向makefile。^_^

編輯:被接受的答案確實是我們的問題,雖然問題與DJGPP,而不是Windows。 (Windows似乎沒有命令限制。)解決方案是使用MinGW而不是DJGPP進行編譯,後者立即解決了該問題。多謝你們!

+0

您的路徑設置爲?如果將所有源文件移動到其他目錄(不稱爲「核心」)並嘗試在那裏,你會得到不同的行爲嗎?我問這是否是一個巧合,編譯OK的一個.c文件恰好與當前目錄具有相同的名稱。 – 2008-10-19 03:11:53

+0

什麼讓我感到不安是批處理文件,是使用DJGPP(GNU工具鏈的經典DOS端口)而不是更現代的MinGW(GNU工具鏈的Windows端口)。 Jeremy Ruten的回答中提到了127個字符的DOS命令行限制...... – CesarB 2008-10-19 03:20:10

回答

5

工作的行長度爲126個字符,其他行長度爲130和136個字符。問題是有127個字符的限制。我不知道如何解決這個問題,但也許使會解決它嗎?...

0

添加-v到gcc命令行。 gcc實際上是一個驅動程序,它運行其他幾個輔助程序(傳統上,預處理程序,編譯程序和彙編程序); -v使它在執行時顯示它們的命令行,並啓用詳細模式。有了這個,你可以看到它失敗的地方。

0

如前所述,DJGPP make(或Bash)甚至簡單的響應文件可以解決這個問題,所以這不是問題。 DJGPP的功能仍然很棒。 (請參閱ELF端口或Japheth的HX mod。)