cygwin內含mingw，於是就把原有的mingw解除安裝了。但是由於某種原因（原因在最後介紹）gcc在windows命令列下就不起作用了（執行後並不產生編譯結果），即使path設定正確。
採用掩蔽dll的方法。將gcc放置於乙個新建的資料夾，並執行，會出現缺失dll，逐個加上這些dll後能執行通過，但結果仍是無法產生輸出檔案。估計仍是有相關的dll沒有被鏈入。但是使用dependency walker也無法發現（顯然在執行而言，裝入資料夾的這些dll已經足夠了）。這些dll是：
cygwin1.dll
cygintl-8.dll
cygiconv-2.dll
於是就想通過暴力方法找到這個缺失的dll，想法很簡單，就是逐個裝入cygwin的bin資料夾下的那些dll，直到gcc執行能輸出編譯結果為止，這樣最後裝入的那個dll有很大的可能是唯一缺失的那個dll。cygwin下的dll毛毛多，當然得用程式實現，結果發現那個依賴的dll是cygintl-3.dll。
這個程式工具選取，編譯和執行也很有講究。如果繼續用那個cygwin下的gcc會有諸多不便。於是用vc，但其中用了cygwin下的一些命令，例如ls，因為其輸出結果比dir要規整。因為system命令中cd是不起作用的，最終生成檔案要放在那個裝有待測gcc.exe的資料夾中，這個資料夾放在cygwin/mingw下。具體**貼在最後。
現在講一下產生這個問題的真正原因。這個原因很可笑，是因為存在另乙個應用，它也用到了cygwin相關的dll，但版本較舊。而它的bin資料夾又在%path%中，而新加的bin（包括cygwin本身的bin）都在它之後。估計dll的搜尋也是從%path%中依次進行的，於是鏈入的都是舊版本的，從而導致錯誤。這樣一來看來剛才的這些抽取工作都是不必要的。鬱悶。
#include
#define dllnamebufsize 128
#define dllnamebufsize 128
#define cmdbufsize 256
#define recvbufsize 256
typedef
struct
_dllinfo dllinfo;
struct
_dllinfo
;dllinfo *g_pdlllist;
dllinfo *g_pdlllisttail;
void
parsedllfilenames(file *fdl)
//printf("%s/n", dllnamebuf);
pdll = (dllinfo*)malloc(
sizeof
(dllinfo));
strcpy(pdll->filename, dllnamebuf + strlen(
"../bin/"
));pdll->pnext = 0;
if(g_pdlllist==0)
else}}
intcheckfileexistence()
fgets(recvbuf, recvbufsize, f);
if(0 == strncmp(recvbuf, psztarget, strlen(psztarget)))
else
}void
tryaddingdlls()}}
intmain(
void
)parsedllfilenames(fdl);
fclose(fdl);
printf(
": parsing dll names ok./n"
);tryaddingdlls();
return0;}
cygwin和mingw的區別
1 使用區別 cygwin gcc和mingw都是gcc在windows下的編譯環境，但是它們有什麼區別，在實際工作中如何選擇這兩種編譯器。cygwin gcc完全可以和在linux下的gcc化做等號，這個可以從boost庫的劃分中可以看出來端倪，cygwin下的gcc和linux下的gcc完全使用...
MinGW與Cygwin的關係與差別
part1 共同點 cygwin gcc和mingw都是gcc在windows下的實現。gcc 它是一款原來只能在linux系統上使用的開源c語言編譯器，後來移植到了windows作業系統上 以mingw和cygwin為代表 part2 不同點 mingw是windows上gcc的乙個實現，loca...
從JDBC中取出資料
首先要建立連線，為了在第二次鏈結的時候，不用重新建立connection 浪費，所以在建立連線的時候，先判斷當前物件的conn是否為null，是才進行建立，否則直接使用已有。private static connection conn null public connection getconnec...