『壹』 在紅旗下用gcc編譯器運行以下兩段代碼結果為什麼不一樣
用gcc編譯
以下是例子
實例代碼:
/*
* hello.c - Canonical "Hello, World!" program
*/
#include <stdio.h>
int main(void)
{
printf("Hello,linux programming world!\n");
return 0;
}
在命令行上鍵入以下命令編譯和運行這段程序:
$gcc hello.c -o hello
$./hello
Hello, Linux programming world!
第一行命令告訴gcc對源代碼hello.c進行編譯和鏈接,並使用-o參數指定創建名為hello的可見程序.第二行命令執行hello這個程序,第三行是程序的執行結果.
其實,gcc首先運行預處理程序cpp來展開hello.c中的宏並在其中插入#include文件所包含的內容:然後把預處理後的源代碼編譯成為目標代碼;最後,鏈接程序ld創建一個名為hello的二進制文件.
現在我們來通過手工操作重新創建這些步驟,以逐步執行編譯過程.第一布是運行預處理器.使用-E選項告訴gcc在預處理後停止編譯過程:
$gcc -E hello.c -o hello.cpp
此時查看hello.cpp會發現stdio.h的內容確實都插到文件里去了,而其他應當被預處理的標記也做了類似處理.
下一步是將hello.cpp編譯為目標代碼.可使用gcc的-c選項來完成:
$gcc -x cpp-output -c hello.cpp -o hello.o
-x選項告訴gcc從指定的步驟開始編譯,在本例中也就是編譯器處理後的源代碼(cpp-output).
gcc是怎麼知道如何處理某種特殊類型的文件呢?它是依靠文件的擴展名來決定如何正確處理該文件的.
——————————————————————————————
擴展名 類型
.c C語言源代碼
.C,.cc C++語言源代碼
.i 預處理後的C源代碼
.ii 預處理後的C++源代碼
.S,.s 匯編語言源代碼
.o 編譯後的目標代碼
.a,.so 編譯後的庫代碼
———————————————————————————————
最後,鏈接目標文件,生成二進制代碼.
$gcc hello.c -o hello
『貳』 在linux下用GCC編譯的C程序變數自加的結果和TC2.0下不一樣
這個是c語言的「經典」問題，不同的編譯器對公式的處理優先順序不同。所以，在不能完全控制編譯器環境時，千萬不要隨便的使用這種混成的公式。
印象里我曾經看到過專門講解這個問題的文章。
『叄』 同一個程序vc++6.0和gcc運行的結果不同
軟體版本所需條件不同而已，Windows和Linux肯定有區別，不用在意這些。
『肆』 為什麼我寫的.cpp文件 用gcc編譯後會出現左圖的結果為什麼不像右圖的結果
改用g++或gcc -lstdc++
對於文件名後綴為cpp的文件gcc編譯器會自動認為是c++程序，編譯階段沒問題，但是因為gcc命令不能自動和C＋＋程序使用的庫聯接，所以連接時出錯。因此需要手動加上-lstdc++參數或改用g++即可。
『伍』 關於同一段代碼在gcc和dev-c++中結果不一樣的問題
你的代碼貌似有問題，我看花括弧有不配對的。
最好把代碼也貼上來。不要截圖。
『陸』 Linux下的gcc編譯後生成Linux下的可執行文件，window下gcc編譯後是exe文件，為什麼不一樣啊是怎麼做到的
首先，這win和Linux下的gcc功能是一樣的，實際的gcc.exe和linux下的gcc這兩個文件不是一樣的，他們畢竟需要在工作在不同的平台上，而且他們做的一些工作是有區別的。
編譯過程是把源文件翻譯成機器碼，然後鏈接成一個整體，拼接成一個文件。不管是win下的exe還是Linux下的ELF，都是按照一定規范來的，比如頭部放什麼，尾部放什麼，中間又存哪些信息等。但是，如果要編譯出正確的可執行的文件，不同的操作系統里就必須按照不同的規范來組織這個文件。
這些文件的執行過程，並不是說它們可以直接執行，執行的時候，系統把它們從磁碟上，讀到內存中，經過一系列的前期工作，才可以最終執行起來，這個前期過程都是操作系統來搞定的。
你不應該問gcc是怎麼做到的，而應該問gcc為什麼需要這樣。如果你需要知道細節，去看《程序員的自我修養》
『柒』 為什麼用GCC 編譯這個不報錯。。。但是就是結果不對呢。。。。name[20]可以用這樣的輸入方式嗎
發現2個問題：
1。"%s,%c,%d" 在scanf里這樣排，你輸入的時候也必須以逗號分開，建議取消逗號，用回車鍵分開輸好了
2.scanf那個要用 stu.name ，這個就是地址，沒必要加其他的東西，你寫的這樣的方式是指 取出stu.name第20個字元的地址，而且這個地址已經越界了，最多到第19個字元
『捌』 gcc編譯錯誤！
提示說需要-fPIC編譯，然後在鏈接動態庫的地方加上-fPIC的參數編譯結果還是報錯，需要把共享庫所用到的所有靜態庫都採用-fPIC編譯一邊才可以成功的在64位環境下編譯出動態庫。
這里的-fPIC指的是地址無關代碼
你看看這里的這篇文章吧：http://www.cnblogs.com/lightsalt/archive/2011/10/19/2217628.html