伊莉討論區

標題: 關於templates 的問題（已解決） [打印本頁]
作者: weirdococo    時間: 2017-5-20 11:50 PM     標題: 關於templates 的問題（已解決）

本帖最後由 weirdococo 於 2017-6-4 02:37 PM 編輯

先上code
我嘗試的把那個templates 寫的libary編譯成為Dynamic-link library，
雖然我認為一般templates好像不行做成Dynamic-link library（就我上了一個學期的cpp認知），
但是我看到了ruby 或 perl 或 python 用了boost，一個cpp的templates library。
感覺其起來很奇怪，一般來說那些script language用C++ or C library都要先把它編譯
為Dynamic-link library，但是純templates不可能定型（實例化），
卻有人用boost，不是很詭異嗎？

所以我嘗試著把templates用g++編譯，g++ --std=c++11 -c lib.cpp -o lib.so還真的可以
編譯，但是沒有標頭檔根本不知道怎麼用？
所以我該如何去寫一個template Dynamic-link library?


補充內容 (2017-5-20 11:59 PM):
題外話Dev C++到底要怎麼用compiler options？

補充內容 (2017-5-22 04:22 PM):
我寫錯了，我把l該寫在lib.cpp寫到lib.hpp裡面，事實上我沒有想要寫lib.hpp 。

補充內容 (2017-5-22 04:33 PM):
其實說道一個重點，我也沒有把template 的宣告何定義分開了來寫的經驗，也不知道要如何這樣做。

補充內容 (2017-5-22 04:44 PM):
還有，對於php來說，它用態函式庫根本不用頭文件，所以這已問題對C++自己來說，因該不存在，只要全寫在hpp裡面就好了！

補充內容 (2017-5-22 04:51 PM):
動態函式庫對C++感覺是一個可有可無的存在，真的有人會在執行時期才把要的程式連結在一起嗎？

補充內容 (2017-5-22 04:54 PM):
況且要執行的電腦可能還沒有連結器，能連在一起嗎？我只是上了一學期C++的大一新生，所以有很多手法沒看過，問了個蠢問題，也請多多包含。
作者: weirdococo    時間: 2017-5-22 04:26 PM

也做是說我想要把
  1. namespace HigherOrderFunctions {

  3.         uint64_t doubleMe ( uint64_t tmp ) {
  4.                 return  tmp * 2;
  5.         }

  7.         //filter
  8.         template < typename Collection, typename filterOperate  >
  9.                 Collection filter( Collection collection, filterOperate operate ) {
  10.                         collection.erase( std::remove_if(collection.begin(), collection.end(),
  11.                         [operate]( typename Collection::value_type i ) { return !operate(i); } ),
  12.                                         collection.end() );
  13.                         return collection;
  14.                 }

  16.         //map
  17.         template < typename Collection, typename mapOperate  >
  18.                 Collection map( Collection collection, mapOperate operate ) {
  19.                         std::transform( collection.begin(), collection.end(), collection.begin(), operate );
  20.                         return collection;
  21.                 }

  23.         //zip
  24.         template < typename Collection, typename biOperate >
  25.                 Collection zip( Collection firstCollection, Collection secoundCollection, biOperate operate ) {
  26.                         std::transform( firstCollection.begin(), firstCollection.end(), secoundCollection.begin(), firstCollection.begin(), operate );
  27.                         return firstCollection;
  28.                 }

  30. }
複製代碼
寫為share libaray，給其他程式（甚至是其他程式語言）用，其實也不是這個，這只是一時想到的範例，最主要是其他程式語言和c++結合的問題！
作者: weirdococo    時間: 2017-5-22 05:05 PM

本帖最後由 weirdococo 於 2017-5-22 05:19 PM 編輯

還有很詭異的是，我嘗試要去編譯它是可以編譯的（在win10)，過程如下:

  1. frank@LAPTOP-8R9HO8BI ~/d/tmp/shareLibTest
  2. $ g++ -v
  3. 使用內建 specs。
  4. COLLECT_GCC=g++
  5. COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/5.4.0/lto-wrapper.exe
  6. 目的：x86_64-pc-cygwin
  7. 配置為：/cygdrive/i/szsz/tmpp/gcc/gcc-5.4.0-1.x86_64/src/gcc-5.4.0/configure --srcdir=/cygdrive/i/szsz/tmpp/gcc/gcc-5.4.0-1.x86_64/src/gcc-5.4.0 --prefix=/usr --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc --docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C --build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=x86_64-pc-cygwin --without-libiconv-prefix --without-libintl-prefix --libexecdir=/usr/lib --enable-shared --enable-shared-libgcc --enable-static --enable-version-specific-runtime-libs --enable-bootstrap --enable-__cxa_atexit --with-dwarf2 --with-tune=generic --enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable-graphite --enable-threads=posix --enable-libatomic --enable-libcilkrts --enable-libgomp --enable-libitm --enable-libquadmath --enable-libquadmath-support --enable-libssp --enable-libada --enable-libgcj-sublibs --disable-java-awt --disable-symvers --with-ecj-jar=/usr/share/java/ecj.jar --with-gnu-ld --with-gnu-as --with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix --without-libintl-prefix --with-system-zlib --enable-linker-build-id --with-default-libstdcxx-abi=gcc4-compatible
  8. 執行緒模型：posix
  9. gcc version 5.4.0 (GCC)

  11. frank@LAPTOP-8R9HO8BI ~/d/tmp/shareLibTest
  12. $ cat lib.cpp
  13. #include <cstdint>
  14. #include <vector>
  15. #include <algorithm>
  16. #include <numeric>

  18. namespace HigherOrderFunctions {

  20.         uint64_t doubleMe ( uint64_t tmp ) {
  21.                 return  tmp * 2;
  22.         }

  24.         //filter
  25.         template < typename Collection, typename filterOperate  >
  26.                 Collection filter( Collection collection, filterOperate operate ) {
  27.                         collection.erase( std::remove_if(collection.begin(), collection.end(), [operate]( typename Collection::value_type i ) { return !operate(i); } ),
  28.                                         collection.end() );
  29.                         return collection;
  30.                 }

  32.         //map
  33.         template < typename Collection, typename mapOperate  >
  34.                 Collection map( Collection collection, mapOperate operate ) {
  35.                         std::transform( collection.begin(), collection.end(), collection.begin(), operate );
  36.                         return collection;
  37.                 }

  39.         //zip
  40.         template < typename Collection, typename biOperate >
  41.                 Collection zip( Collection firstCollection, Collection secoundCollection, biOperate operate ) {
  42.                         std::transform( firstCollection.begin(), firstCollection.end(), secoundCollection.begin(), firstCollection.begin(), operate );
  43.                         return firstCollection;
  44.                 }

  46. }


  49. frank@LAPTOP-8R9HO8BI ~/d/tmp/shareLibTest
  50. $ g++ -fPIC --std=c++11 -c lib.cpp -o lib.so
  51. lib.cpp:1:0: 警告：-fPIC ignored for target (all code is position independent)
  52. #include <cstdint>
複製代碼








補充內容 (2017-5-22 05:11 PM):
正在嘗試如何用Dev C++寫出來，因為命令列工具（像是make git cmake)都是些過時的東西，業界都用些IDE不用這種過氣的工具(老師說的）


補充內容 (2017-5-22 05:12 PM):
雖然IDE比較難學，但還是值得的。

補充內容 (2017-5-22 05:14 PM):
只是好難用，像是Dev C++我還找不到C++11選項。
作者: ren1244    時間: 2017-5-22 06:53 PM

可以編譯，未必能鏈結。
目前main.cpp能運作的原因是你有include lib.hpp
你可以試試看刪掉so檔，main產生的執行檔應該還是可以執行
因為他根本沒去使用動態鏈結。
只是根據lib.hpp內的樣板內容實例化了
至於給其他程式語言使用我不清楚
那些語言要引用C++寫的函式庫應該會有相關文件
我的猜測需要指定型別而不能用弱型別的方式呼叫C
作者: weirdococo    時間: 2017-5-22 07:44 PM

ren1244 發表於 2017-5-22 06:53 PM
可以編譯，未必能鏈結。
目前main.cpp能運作的原因是你有include lib.hpp
你可以試試看刪掉so檔，main產生 ...

了解，它根本沒有用到我編譯的 lib.so，其實我預設它會編譯錯誤，所以編譯出東西很驚訝。

會有這樣的問題是因為一般python的教學只有教如何調用c程式，沒有用C++，
更沒有用template，但是看到用內含大量template的C++ 模組，也有不少
被包到python裡面，所以決得很奇怪，然後剛好學校在教C++，自然會想
要python C++ 混著用，想說只有用到速度問題時用C++這樣子。

突然發覺到有藍色小舖這個中文網站可用，以前以為只能去stackoverflow問，
以我的英文能力，我很久才能寫出一個問題，有了這個網站實在是很方便。
作者: chevylin0802    時間: 2017-5-22 07:48 PM

本帖最後由 chevylin0802 於 2017-5-22 08:31 PM 編輯
weirdococo 發表於 2017-5-22 05:05 PM
還有很詭異的是，我嘗試要去編譯它是可以編譯的（在win10)，過程如下:




在微軟的windows環境下
.so檔是不能用的
所以沒有任何作用
Windows的動態程式庫是.dll檔
因為.so檔的檔案格式是Unix Like的系統在使用的
至於make cmake根本沒有過時的問題
只要在Linux環境寫程式的人
就一定會常常使用
即使是使用IDE
也一樣會自動產生出make所需的Makefile檔
所以你們老師真的只懂得玩微軟
對於IT業界常用的開發環境根本搞不清楚
就算是Android所需要的Native Libriries
也都是用命令列打make編譯都不知道
才老是以為make過時

動態連結有它當初的背景
早期在Intel386/486的時代
記憶體大多只有2M最多也才8M左右
那是當初記憶體的製造技術限制的關係
而硬式磁碟機也才剛問世不久
容量也才20M到50M左右
如果不發展動態連結技術
以當時的windows3.0/3.1根本硬碟裝不下
而且以當時的windows所採用的虛擬86記憶體管理模式
很多視窗程式根本就無法執行
所以才會出現這種在執行階段才連結程式庫的做法
起碼可以讓同時執行的多個程式
使用同一個程式庫的時候
不至於讓記憶體使用量爆增
所以它在當初的背景是很好用的
到了後來出現許多新的直譯程式語言時動態連結程式庫再次提供了直譯程式語言更大的擴充性
所以動態連結程式庫的作用到了現在
成了不可或缺的角色

至於直譯程式在透過直譯器執行階段
從來就不會去使用標頭檔
Java即使要執行Jni時
也一樣不需要標頭檔
而是Java需要先寫出Java Jni class
然後用Java去產生標頭檔
作為C/C++的Jni函式的標準格式用
同樣的
每一種直譯式程式語言
對於引用動態程式庫的C/C++的程式原始碼的格式有不同的要求
並不是你想怎麼做都可以
作者: weirdococo    時間: 2017-5-22 09:28 PM

chevylin0802 發表於 2017-5-22 07:48 PM
在微軟的windows環境下
.so檔是不能用的
所以沒有任何作用

剛剛去stackoverflow問了，
他說你要在CPP大一邊把程式打包，有一些東西可以用
像是SWIG   Boost.Python等東西可以用，這是讓人很興奮的，
終於可以融合我所學的所有程式語言，如何去使用我會在研究，
但是看他的support C++的 Lambda functions 就決得很有趣，
隨然好像有些東西（主要是C++11）不支持，但對我來說因該夠用。
作者: chevylin0802    時間: 2017-5-22 10:08 PM

本帖最後由 chevylin0802 於 2017-5-22 10:41 PM 編輯
weirdococo 發表於 2017-5-22 09:28 PM
剛剛去stackoverflow問了，
他說你要在CPP大一邊把程式打包，有一些東西可以用
像是SWIG   Boost.Python ...


這不需要擔心
以boost.Python來說
就是你把一套支援的c++11的程式庫再進一步重新以非c++11的cpp文件封裝過都沒差
照著可以順利運作
只要你重新封裝的cpp程式有按照boost.python所要求的格式即可
所以你根本不需要擔心
就算使用c++14的規範寫出來的程式庫
也同樣可以比照辦理

只是通常實務應用上
多數都是為了硬體的支援而設計C/C++的介面接口給直譯程式
或者有遇到執行效能考量的前題下
才會去設計那些動態程式庫
原因仍然出在企業界對於程式維護以及程式擴充時盡可能可以降低問題所致
畢竟許多程式設計師不見得懂很多程式語言
尤其是很多Java程式設計師
完全不會寫C/C++的Jni
這種情況是經常發生的
所以同樣的事情
企業往往會盡可能的不做跨不同程式語言的介面
原因就是如此
也因此通常類似這種native介面程式庫
往往多半都是由自由軟體工作者在提供

現在其實關於python也一樣有版本上的選擇上的分歧
等到你出了社會開始工作時
很多程式語言的規範可能又改了
最讓人傷腦筋的是
不管是Ruby,python,php還是其他
網路上程式庫的數量將會幾乎以等比級數的速度增長
其中可能有99趴的程式庫是沒有用的垃圾
可是卻增加你尋找適合的程式庫的困難度
所以屆時很可能會讓許多人欲哭無淚
作者: weirdococo    時間: 2017-5-23 07:31 PM

本帖最後由 weirdococo 於 2017-5-23 07:32 PM 編輯
weirdococo 發表於 2017-5-22 05:05 PM
還有很詭異的是，我嘗試要去編譯它是可以編譯的（在win10)，過程如下:

IDE難用，是因為我的記憶比較差，很多細節我都記不住，
像是用python寫一些小東西，遇到速度問題用C寫，
那就要用兩個ide，兩種project file，那裡該設定些什麼這又該設些什麼，
把兩種混合的時候真的是一種災難，不談後來ide升級後，
project file改變如何移植的問題就讓我頭大了。
作者: ren1244    時間: 2017-5-23 11:12 PM

這就是為什麼有人只用文字編輯器寫程式了
(或是只把IDE當編輯器用)
因為程式如何編譯是自己控制的
比較不會有移植的問題
IDE把要做的事情用他自己的格式紀錄自動化的編譯
雖然方便，但不透明
(去研究project file就失去原本的意義了)

python部分，我也是剛碰不久
但我都是文字編輯器寫好後在cmd下跑，沒開過IDE

考慮到IDE升級或是移植性的問題
在進入公司前入境隨俗之前(如果公司有綁IDE環境)
我還是覺得makefile比較有用
作者: chevylin0802    時間: 2017-5-24 08:33 AM

本帖最後由 chevylin0802 於 2017-5-24 08:35 AM 編輯
ren1244 發表於 2017-5-23 11:12 PM
這就是為什麼有人只用文字編輯器寫程式了
(或是只把IDE當編輯器用)
因為程式如何編譯是自己控制的

最早的IDE其實是1984年寶蘭搞出來的Turbo C
到現在也30幾年了
連除錯的功能都做在裏面
所以IDE的歷史真的是很久
只是現在的IDE弄得非常的複雜就是了

現在的Makefile也一樣很複雜
事實上它也幾乎都是自動完成的
你會常常看到有很多的開源專案都需要用到configure去自動產生出Makefile檔
所以它也等於跟IDE做類似的事情
而且有一些IDE其實它也會自動幫你產生出Makefile

作者: chevylin0802    時間: 2017-5-24 08:38 AM

weirdococo 發表於 2017-5-23 07:31 PM
IDE難用，是因為我的記憶比較差，很多細節我都記不住，
像是用python寫一些小東西，遇到速度問題用C寫，
...

開源的專案裏面
確實是有能夠同時給Python跟C/C++使用的多重程式語言的IDE環境
但是最大的問題就是
功能越強大的IDE那麼它的操作複雜度就會越高
尤其是這種多重語言型的IDE
不過能不能在Windows環境下執行
我就不太清楚了
作者: a333221    時間: 2017-5-30 03:56 PM

weirdococo 發表於 2017-5-22 07:44 PM
了解，它根本沒有用到我編譯的 lib.so，其實我預設它會編譯錯誤，所以編譯出東西很驚訝。

會有這樣的問 ...

拿底下的例子去編譯，可以順利編出 .so，不過編出來的 .so 只有 Hello()這函數能用，
不存在 template<typename T> void TemplateHello(T a) 這函數。
還有，你下的參數「$ g++ -fPIC --std=c++11 -c lib.cpp -o lib.so」，-c 是多打了？還是本來就想這樣下？
  1. #include <stdio.h>
  2. void Hello()
  3. {
  4.         print f("Hello\n");
  5. }

  7. template<typename T> void TemplateHello(T a)
  8. {
  9.         print f("TemplateHello %d\n", (int)(a));
  10. }
複製代碼
作者: weirdococo    時間: 2017-5-31 03:36 PM

本帖最後由 weirdococo 於 2017-5-31 03:38 PM 編輯
a333221 發表於 2017-5-30 03:56 PM
拿底下的例子去編譯，可以順利編出 .so，不過編出來的 .so 只有 Hello()這函數能用，
不存在 template vo ...

-c 是本來就想這樣下的，我對這個option的理解是不要用linker，看起來好像是不必要的，但想說加上去也沒差。
作者: a333221    時間: 2017-5-31 06:17 PM

weirdococo 發表於 2017-5-31 03:36 PM
-c 是本來就想這樣下的，我對這個option的理解是不要用linker，看起來好像是不必要的，但想說加上去也沒差 ...

要編譯 .so 不要下 -c，-c 是編 object file 用的
另外，為何你這裡不想用 linker
作者: weirdococo    時間: 2017-5-31 07:42 PM

本帖最後由 weirdococo 於 2017-6-1 12:17 AM 編輯
a333221 發表於 2017-5-31 06:17 PM
要編譯 .so 不要下 -c，-c 是編 object file 用的
另外，為何你這裡不想用 linker ...

其實我不知道so和dll有甚麼差別，特別是我在用cygwin或是mingw，
以前好在ubuntu上測試過不論甚麼副檔名php、perl都可以用，所以不太在意，
然後對shared library 的認知，他就是dynamic library，也就是說是經過不同
處理的 object file，在執行期的時候才連結(至於是不是用linker就搞不清楚了)，
也就是說它在編譯時期不會用到linker!所以才會想加上-c
剛剛去上網查了一下，完整版因該是
  1. #include <stdio.h>
  2. #include <string.h>
  3. #include <stdint.h>

  5. uint64_t doubleMe(uint64_t var) {
  6.   puts("this is double me");
  7.   return 2 * var;
  8. }
複製代碼
  1. gcc -c -Wall -Werror -fpic myLib.c
  2. gcc -shared -o mySharedLib.so myLib.o
  3. LD_LIBRARY_PATH=/home/username/foo:$LD_LIBRARY_PATH
  4. gcc -Wall -o test main.c -lmyLib
複製代碼


實際上這樣就可以給script language用了(用perl測試)
  1. main.so: main.c
  2.     $(CC) -shared -fPIC  main.c  -o main.so  
複製代碼

  1. #!/usr/bin/env perl6
  2. use v6;
  3. use NativeCall;

  5. sub doubleMe(uint64) returns uint64 is native('./main.so')  { * }
  6. say doubleMe(100);
複製代碼




作者: a333221    時間: 2017-5-31 09:32 PM

weirdococo 發表於 2017-5-31 07:42 PM
其實我不知道so和dll有甚麼差別，特別是我在用cygwin或是mingw，
以前好在ubuntu上測試過不論甚麼副檔名ph ...

so 和 dll 在概念上是一樣的東西，只是 so 是 linux 用、dll 是 windows，

兩者的格式不同，所以 windows 底下無法使用 so，linux 下不能用 dll，

不過若是在模擬器(像 cygwin)上執行，那就另當別論了

沒接觸過 php 和 perl，但如果在 ubuntu 下 so 檔和 dll 檔它們都可以用，

個人會把它理解成 php 和 perl 在使用 library 這方面提供了豐富的支援。

linker 和「在執行期的時候才連結」裡的連結是不一樣的東西，一種連結

是將所有的 .o 檔整合成 .so (-c 指的是不要做這種連結) ，另一種連結是

程式在執行時載入其它的 library
作者: chevylin0802    時間: 2017-6-1 10:49 AM

本帖最後由 chevylin0802 於 2017-6-1 10:52 AM 編輯
weirdococo 發表於 2017-5-31 07:42 PM
其實我不知道so和dll有甚麼差別，特別是我在用cygwin或是mingw，
以前好在ubuntu上測試過不論甚麼副檔名ph ...

這是你的理解錯誤
gcc/g++雖然是compiler
但它也可以自動呼叫linker來完成它的工作
所以有些事情也難怪你會不了解
編譯產生動態連結程式庫的過程裏
gcc/g++都會自動去呼叫Linker來進行程式庫的產生
所以如果使用了-c的選項
就無法產生出.so或.dll檔
因為它就跟產生可執行程式一樣需要連結的過程
唯一的不同點就是在於程式庫沒有main的函式
而動太聯結程式庫也不會去把起始目的檔cs0.o/cs1.o/cs2.o等檔案連結進來
而cs0.o/cs1.o/cs2.o等組合語言所產生出來的目的檔
內含的才是所有可執行檔的程式的執行起始點
也就是一個被稱之為_start的標籤
至於main()也只不過是被呼叫的
當你把可執行檔裏的main跟cs0.o/cs1.o/cs2.o這些連結拿掉之後
就是所謂的動態連結程式庫
概念就是如此
所以其實只要你想要產生動態連結程式庫
就必需要透過Linker才能幫你產生


作者: a333221    時間: 2017-6-2 12:03 AM

本帖最後由 a333221 於 2017-6-2 12:06 AM 編輯
weirdococo 發表於 2017-5-31 07:42 PM
其實我不知道so和dll有甚麼差別，特別是我在用cygwin或是mingw，
以前好在ubuntu上測試過不論甚麼副檔名ph ...

補充一點資訊給你參考，

不管今天要產生的是可執行檔或動態連結檔（ windows 叫 dll，linux 稱 so，mac 名為  dylib），

寫好的 .c 檔第一步被編譯成 object file（常見的副檔名有 .obj 和 .o），

然後第二步是將這些 object file 連結成可執行檔或動態連結檔，

過程中會因為所下的參數不同稍有差異，但先編譯後連結的流程是一樣的，

在細一點，或許還會聽到中間會先產生 .s 檔（知不知道有這步個人覺得影響不大），

so 能順利建置出來不表示它就能夠正常運作，

你可以用 file lib.so 比較一下你有下 -c 和沒下 -c 產生出來的 so 有什麼差異。

另外，在載入 library 的部分，有一種是執行檔啟動時就載入，還有一種是需要時才載入，

你給的例子是前者，執行檔啟動時就載入







作者: chevylin0802    時間: 2017-6-2 01:30 PM

a333221 發表於 2017-6-2 12:03 AM
補充一點資訊給你參考，

不管今天要產生的是可執行檔或動態連結檔（ windows 叫 dll，linux 稱 so，mac  ...

你所講的過程當中會產生出的.s檔的問題
現在基本上已經很少人知道這件事情了
甚至也有很多人不知道gcc允許在程式碼裏面寫組合語言的程式碼
要講這一步大不大就只有看學習C/C++的人願不願意去了解程式碼被編譯後所產生的組合語言長什麼樣子
因為這會讓不少人了解C++的程式, 尤其是具備RTTI的template物件, 究竟會造成系統多大的負擔
當然也包括許多人習慣採用多層迴圈的人深入去了解
至於你說library被載入的兩種情況
其實都需要採用同樣的編譯選項來做
只是差別在於連結主程式的時候
如果是執形時期就要載入的話
那麼就是由作業系統自己去找到SO檔載入進來就可以
但還有一種是屬於Plugin式的情況
在Unix/Linux系統來講那稱之為Dynamic Linking
必需要在連結的時候也把libdl.so檔一起連結進來
因為程式碼裏面會使用dlopen將soname指定在裏面
就跟其他程式語言需要使用到原生程式庫時的動作是一樣的
這種手法其實並不是很新鮮的手法
早在許多程式需要用到Plugin的時候
都是採取這個方式來載入指定名稱的程式庫

有-c的選項並不會跟沒有-c的選項產生什麼大的差異性
因為gcc/g++如果要建立動態程式庫的時候都需要採用-shared以及-soname的參數
同時在從C/C++編譯成目的檔的時候還需要給-fPIC的參數
畢竟從一開始在產生.bss區段的時候就會因為參數的不同而有不同的產生方式
而-shared則是通知連結器對於檔案格式採取動態程式庫的格式產生而非鏡態方式
至於-soname的這個部份則是會在動態程式庫的資料標頭將名稱放進裏面
作者: a333221    時間: 2017-6-3 12:35 AM

chevylin0802 發表於 2017-6-2 01:30 PM
你所講的過程當中會產生出的.s檔的問題
現在基本上已經很少人知道這件事情了
甚至也有很多人不知道gcc允 ...

大大，動態連結函數庫的東西我自己有在接觸，

相關知識略懂一些，所以我們不討論這方面的內容。

-c 和 -shared，-soname，-fPIC 是四種不同的概念，

依使用需要而下對應的參數，這幾個沒有誰能取代誰的情形，

所以感到困惑，為何你認為有沒有  -c 差異不大？

底下的下法

        gcc a.c b.c -shared -fPIC -c -o lib.so

會得到

        gcc: fatal error: cannot specify -o with -c, -S or -E with multiple files
        compilation terminated.

當把 -c 拿掉，便可順利建置出想要的 lib.so


      
作者: chevylin0802    時間: 2017-6-3 02:00 AM

本帖最後由 chevylin0802 於 2017-6-3 02:12 AM 編輯
a333221 發表於 2017-6-3 12:35 AM
大大，動態連結函數庫的東西我自己有在接觸，

相關知識略懂一些，所以我們不討論這方面的內容。


我也講得很清楚，在更前面的帖子就已經提到，使用-c的參數時，gcc/g++都只會進行編譯成目的檔的結果，也因此它不會是程式庫。因為-c的參數代表的就是不使用連結器。所以輸出檔不能是so檔。但是當目的檔再次經過連結器產生出的so檔，跟不使用-c參數而一次到位的方式所產生的so檔，應該是要一致的。可是你卻說有使用-c跟沒有-c所做出來的so檔的檔案大小卻不相同，所以才覺得奇怪。
而且還有一點是，執行時期載入的程式庫，跟透過dlopen載入的兩種載入方式，程式庫會不一樣？這讓我感到納悶。因為就我所知的是，只有主程式的部份，會因為dlopen的關係而需要多連結libdl.so的程式庫，但是對於需要被連結的程式庫來說，並沒有什麼不同。而且這兩種方式，我以前還做過不少次。並不會記錯。但是你的講法卻是說程式庫會因為不同的載入方式而有所不同，這點就讓我感到奇怪。
作者: a333221    時間: 2017-6-3 01:39 PM

chevylin0802 發表於 2017-6-3 02:00 AM
我也講得很清楚，在更前面的帖子就已經提到，使用-c的參數時，gcc/g++都只會進行編譯成目的檔的結果，也 ...

大大，你覺得奇怪的點都是我沒有說過的東西，

加上兩個不是新手的人在討論怎麼建置動態連結函數庫，以及如何載入意義不大，

所以對這篇討論文將不再有所回覆！
作者: CoNsTaRwU    時間: 2017-8-3 06:44 AM

提示: 作者被禁止或刪除 內容自動屏蔽



歡迎光臨 伊莉討論區 (http://www1357.eyny.com/) Powered by Discuz!