公告版位
星落的瞬間!放棄的後悔是永遠!

現在改到UE4的Git Hub了

https://github.com/damody/UE4-ThirdParty/tree/damody

 

Donate Damody

 

這是一個想要幫助大家輕鬆的站在巨人的肩膀的想法。
I want to help everybody to easy use c++ libraries. 目前將所有編好的程式庫都放在google code上,
Now the compiled libraries are all put on google code. 網址: http://code.google.com/p/library-prebuilt-for-windows/
有人要寫 nuget 或 visual studio 自動下載外掛嗎?
Is there anyone want to help me put this on nuget or visual studio plugin?
相信大家在使用zlib, libpng, fftw ... ... 等程式庫時,都會遇到麻煩的編譯與連結問題,
I think everybody use library like zlib, libpng, fftw...
Always have encounted some compile and linker trouble. 在上上個禮拜,我發現 boost 的 auto_link.hpp 這個神奇的標頭檔竟然會自動幫我連結正確的版本!
Two weeks ago, I found the auto_link.hpp from boost library.
This magic header helped me link correct version of library automatically!!! 耶耶耶耶耶耶耶耶耶耶~~~~~~~~~~~~~
YYYYYYYYYYYYYYYYYYYYAAAAAAAAAAAAAAAAAAA 真是 真是 嚇死我了!!! I am really really surprised.

所以呢,我心中就有一個想法,把目前看得到的開源 程式庫都先編譯好,並把自動連結規則寫好放在 auto_link_libraryNAME.hpp 裡面
So, I have an idea, which is to build all open source library that I know.
And write the auto link rule in the auto_link_libraryNAME.hpp
舉個例來說: 要用 zlib 的人只需要 For example, if you want to use zlib you just need to
#include <auto_link_zlib.hpp> 在連結器的相依性都不用輸入半個字,就會連起來了! 這真是太神奇了!傑克!
You don't have to edit any property in VCProject =>linker=>input=>dependencies. 當然這些"糖果"對很多高手來說也是方便多多呀! 為什麼呢?因為有很多程式庫在 VS2008, msvc-10.0 都不是很好編譯呀~
Of course, these "candy" are also very convenient for pro.
Why? Because many libraries in VS2008, msvc-10.0 are not convenient to compile and link!
mingw configure:
./configure --host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32 --enable-static

目前計畫支援 Now support 一種組合 msvc-11.0 乘四種 MTd MT MDd MD 乘兩種(有些程式庫只有靜態) 動態 靜態
Dynamic Static 乘一種 x64
共 8 種組合,簡單來說100kb的code編完就50mb
Total 8 set, a 100kb code can output 50mb. 如果有任何的高手想要幫忙的話,就
If anyone who know Visual C++ library want to help me 意者寄信吧~ 我在精神上會感激你的XD
This is my email, I will thank you for everything you do! 信箱: http://scr.im/damody 簡單講解一下命名規則
基本上與boost一樣,不同點在於不支援單執行緒。 檔名沒有對 vc9/vc10/vc11 做劃分, 原因在於大部份 c-style 的程式庫是沒有差別的, 只有在 C++-style 才有差,且可以共用auto link標頭檔

NameRule: //static MDd x64 : libzlib-gd-x64.lib //static MD x64 : libzlib-x64.lib //static MTd x64 : libzlib-sgd-x64.lib //static MT x64 : libzlib-s-x64.lib //dynamic MDd x64 : zlib-gd-x64.lib //dynamic MD x64 : zlib-x64.lib //dynamic MTd x64 : zlib-sgd-x64.lib //dynamic MT x64 : zlib-s-x64.lib 基本上就是這樣了,有需要的人就盡量載吧XD
Basically it's all, take it if you need. 對程式庫有問題請聯絡 http://scr.im/damody
And if you have problems with these libraries-prebuilt,
please contact http://scr.im/damody

library list:

 Filename Summary + Labels Uploaded ReleaseDate Size DownloadCount ...
  opencv2.4.4-vc11-x64.7z opencv2.4.4-vc11-x64 6 hours ago 7 hours ago 189 MB 0  
  luabind-0.9.1-vc11-x64.7z luabind-0.9.1-vc11-x64 7 hours ago 7 hours ago 7.3 MB 0  
  freetype-2.4.10-vc11-x64.7z freetype-2.4.10-vc11-x64 31 hours ago 31 hours ago 2.6 MB 2  
  Effects11-vc11-x64.7z Effects11-vc11-x64 2 days ago 2 days ago 3.4 MB 2  
  LuaJIT-2.0.1-vc11-x64.7z LuaJIT-2.0.1-vc11-x64 2 days ago 2 days ago 1.1 MB 1  
  mpir-2.6.0-vc11-64.7z mpir-2.6.0-vc11-64 2 days ago 2 days ago 8.0 MB 0  
  mpfr-3.1.0-vc11-x64.7z mpfr-3.1.0-vc11-x64 2 days ago 2 days ago 2.2 MB 0  
  cryptopp561-vc11-x64.7z cryptopp561-vc11-x64 2 days ago 2 days ago 50.6 MB 1  
  zlib-1.2.7-mingw-x64.7z zlib-1.2.7-mingw-x64 2 days ago 2 days ago 565 KB 2  
  lzo-2.06-mingw-x64.7z lzo-2.06-mingw-x64 2 days ago 2 days ago 1.1 MB 2  
  lzma920-vc11-x64.7z lzma920-vc11-x64 2 days ago 2 days ago 790 KB 2  
  boost_1_53_0-vc11-x64.7z boost_1_53_0-vc11-x64 3 days ago 3 days ago 131 MB 3  
  lua-5.2.1-vc11-x64.7z lua-5.2.1-vc11-x64 Feb 26 Feb 26 697 KB 1

讓地獄深紅的天亮 發表在 痞客邦 PIXNET 留言(3) 人氣()


留言列表 (3)

發表留言
  • novus
  • 暫時沒空幫忙。我覺得一個好用的 package manager 很重要,而且要做到有使用者規模和自願者加入,這是當急要務。在 linux/mingw 下常用的程式庫都可以用平台的 xxx-get, VC 在這方面差很多。


    雖然以前也好幾次有同樣的念頭,不過那時候沒有好的儲存空間,而且等到正事做完之後就會想:管你們去死..XD
  • 恩,超麻煩的,就慢慢做,做到明年應該就可以做到約100個library,目前是想找會用nuget的,不過自己用了一下,還蠻麻煩的,就等vs 11出了,有沒有什麼好用的外掛再看看了XD

    讓地獄深紅的天亮 於 2012/05/01 11:48 回覆

  • 工數三修
  • 最近第一次嘗試自己編譯一個 library

    下載 A library 編譯後它跟我說缺少 B library

    下載 B library 編譯後他又跟我說缺少 C library

    下載 C library 編譯後他又跟我說缺少 D library

    下載 D library 編譯後... 終於 make 成功 Orz

    接下來就是一步一步往回推

    但... 在 Windows 上果然沒那麼簡單

    我是在 MinGW 底下編譯的

    其中一個 library make 完後竟然沒有 .a 檔?!

    還好作者有提供 Win32 的 VS2010 專案

    弄一弄總算弄出個 .lib 改名成 .a 後繼續編譯

    其他還有一堆雜七雜八的狀況不過解決完後都忘記了

    雖然會花好幾天的時間主要是因為自己對 make 不熟的關係

    但還是覺得在 Windows 編譯一個 Open Source 真的好累

    在 Linux 只要 apt-get 或 yum 馬上啪啦啪啦現成的 binary 就安裝好

    什麼相依性的也全部幫你搞定

    在 Windows 就要撞一堆牆才能做到一樣的事 Orz


    P.S: 過這麼久仔細一看才發現 damody 網誌的 icon 是 Elfen lied
  • 高手,只有一隻眼也看得出來~~~
    我以前就是覺得超麻煩的才來貢獻一下,
    不過目前的感覺是,
    會的人不需要我幫,
    不會的人也看不懂我在幹麻= =
    至少給自己一點方便XD

    讓地獄深紅的天亮 於 2013/10/13 22:19 回覆

  • novus
  • 如果樓上常常做這類事,就會知道編譯大型的 library 一直都不是容易的事,就算有 apt 或 yum 對於一堆棘手的版本問題也是束手無策。(但無論如何比 windows 好了一點)

    有個常見的情況是,別人預建的 lib 所依賴的 libc 和你開發環境的 libc 版本不同。或者是別人預建 lib A 和 lib B 同時依賴某個 lib X,但卻依賴不同版本。如果再考慮工作環境的「binary 政策」,有些本來就很麻煩的問題,立時變得幾乎無解。

    通常可以在 chroot 下硬裝看看,但是挽起袖子從 source build 有時也是跑不掉的。

  • 說的沒錯,最近打算編譯 OpenSceneGraph oh no! 又是一個大 project,話說個人最近已經轉移到 x64 的陣營了,記憶體用到爽~,希望不要遇到什麼太舊的 library~ 要改 source code 時就累了,雖然這也是 open source 的方便之處。

    讓地獄深紅的天亮 於 2013/10/13 22:22 回覆

【 X 關閉 】

【PIXNET 痞客邦】國外旅遊調查
您是我們挑選到的讀者!

填完問卷將有機會獲得心動好禮哦(注意:關閉此視窗將不再出現)

立即填寫取消