最近倒騰Linux C/C++項目。以目前的情況來說，要生成編譯（build）一個Linux工程腳本，首選的工具必定是CMake。這也是我之前Linux項目的首選。不過自從VS IDE支持Linux C/C++開發後，也嘗試這通過一些小demo來體驗MS的解決方案。總得來說還可以，但是有個大問題因為一直沒時間搞，就沒有深入。

這裏通過一個假定的場景來說這個問題。

在VS Linux項目裏，如果一個解決方案下面有多個工程，比方說有兩個工程A（.out）和B（.so），當工程A依賴工程B時我們需要設置工程的依賴關系，保證編譯工程A時能先把依賴庫編譯出來。設置方式如下圖：

設置完依賴關系後還要保證編譯A時能夠鏈接到已經生成的libB.so。這需要在工程屬性頁裏Configuration Properties / Linker / Input : Libraries Dependencies裏加上B。當然這還不夠，因為鏈接指定的是so的名字，並沒有指定so的路徑。所以，要找到so必須知道so文件在哪裏。除了使用絕對路徑外，更好的方案顯然是指定庫文件的目錄。正常情況下，類庫文件都會統一編譯到一個指定的目錄下。

在VS的環境裏，本地$(SolutionDir)默認映射到遠程的$(RemoteRootDir)。而$(RemoteRootDir)默認是"~/projects"。所以如果統一將二進制文件編譯到$(SolutionDir)bin\$(Platform)\$(Configuration)的話，對應地，在遠程Linux上會被部署在"$(RemoteRootDir)/bin/$(Platform)/$(Configuration)"目錄下。於是通過屬性頁向Configuration Properties / Linker / General : Additional Library Directories添加"$(RemoteRootDir)/bin/$(Platform)/$(Configuration)"就從理論上解決了鏈接時-lB到哪裏找libB.so的問題了。但是，經過嘗試之後你會發現，這樣做並沒有解決鏈接時找不到libB.so的問題。

之前並沒有長期做Linux開發，所以對GCC編譯選項的使用也就主要花時間看了看各種警告選項。對於大小L的鏈接選項，也是一樣，只是知道是幹嘛，但是對於輸入字串的格式是不是有嚴格要求還真不知道。於是，我就遇到了本文要說的這個問題。只要Additional Library Directories裏的路徑是通過"~"來定位的，就必然會遇到VS環境下編譯時找不到庫文件的問題（當然我並不清楚在Linux上直接使用GCC編譯鏈接是不是會遇到同樣的問題）。

要解決這個問題，要麽向前文說的，使用絕對路徑。這顯然不是個好方法，特別是自定義的類庫比較多的時候。另外一種方法是將"~"使用絕對路徑替換。也就是說將$(RemoteRootDir)的值從"~/projects"改為"/home/user_name/projects"。這就得保證在多個機器上使用VS遠程編譯時機器上的用戶名都是同一個，不然要不停地改，也是作孽。

其實最好的方法是將$(RemoteRootDir)改為"$HOME/projects"。

完~

解決Visual C++ for Linux: -L"~/projects/path_to_lib_folder" 無法設置library search path的問題