怎么把自己写的函数编译到动态库中

Magic_YH 2014-04-11 05:24:30

最近下载了X264最新的库，然后在 x264.h 文件中声明了一个自己的函数 void printVersion(); 然后在 x264.c 中将其实现了，然后用网上的编译方法生成了他的库和可执行程序。

运行可执行程序的时候自己写的函数已经生效了，但是我在VS下调用我自己写的函数时却报错：error LNK2001: 无法解析的外部符号 _printVersion

用VS的dumpbin命令查看列表中没有我自己定义的函数，请问这是为什么，怎样才能将我自定义的函数加到编译出来的库中？

...全文

627 12 打赏收藏转发到动态举报

写回复

用AI写文章

12 条回复

切换为时间正序

请发表友善的回复…

发表回复

Magic_YH 2014-04-18

打赏
举报

去询问了对linux比较了解的人，最后解决了，是跟gcc编译选项有关，编译库的时候需要把对应的文件添加到编译依赖项中。谢谢楼上各位。

赵4老师 2014-04-15

打赏
举报

Determine Which Exporting Method to Use Home | Overview | How Do I | FAQ | Details | Sample To determine which method to use to export functions (a .DEF file or the __declspec(dllexport) keyword), answer the following questions: Will you be continuing to add additional exported functions? Who is using your DLL? For example, is it a third party DLL used by many executables that you cannot rebuild, or is the DLL used only by applications that you can easily rebuild? Pros and Cons of Using .DEF Files Exporting functions in a .DEF file gives you control over what the export ordinals are. When you add additional exported functions to your DLL, you can assign them higher ordinal values (higher than any other exported function). When you do this, applications using implicit linking do not have to relink with the new import library that contains the new functions. This is very important, for example, if you are designing a third-party DLL for use by many applications. You can continue to enhance your DLL by adding additional functionality while at the same time ensuring that existing applications will continue to work properly with the new DLL. The MFC DLLs are built using .DEF files. Another advantage to using a .DEF file is that you can export functions using the NONAME attribute, which places only the ordinal in the exports table in the DLL. For DLLs with a large number of exported functions, using the NONAME attribute can reduce the size of the DLL file. For information about writing a module definition statement, see Rules for Module-Definition Statements. For more information on ordinal export, see Export Functions From a DLL By Ordinal Rather Than By Name. The major disadvantage of using .a DEF file is that if you are exporting functions in a C++ file, you will either have to place the decorated names in the .DEF file or define your exported functions with standard C linkage by using extern “C” to avoid the name decoration done by the compiler. If you need to place the decorated names in the .DEF file, you can obtain them by using the tool DUMPBIN or by using the link switch /MAP. Note that the decorated names produced by the compiler are compiler specific. If you place the decorated names produced by the Visual C++ compiler into a .DEF file, applications that link to your DLL must also be built using the same version of Visual C++ so that the decorated names in the calling application match the exported names in the DLL’s .DEF file. Pros and Cons of Using __declspec(dllexport) Using __declspec(dllexport) is convenient because you do not have to worry about maintaining a .DEF file and obtaining the decorated names of the exported functions. However, you do not have control over the export ordinals that the compiler generates. This method is suitable if, for example, you are designing a DLL for use with an application that you control; if you rebuild the DLL with new exports, you will also have to rebuild the application. What do you want to do? Export from a DLL using .DEF files Export from a DLL using __declspec(dllexport) Export and import using AFX_EXT_CLASS Export C++ functions for use in C-language executables Export C functions for use in C or C++-language executables Import into an application using __declspec(dllimport) Prepare the MFC DLL for use by an application, or Prepare the Win32 DLL for use by an application What do you want to know more about? Importing and exporting inline functions. Mutual imports Decorated names

赵4老师 2014-04-15

打赏
举报

Export from a DLL Using .DEF Files Home | Overview | How Do I | FAQ | Details | Sample A module-definition (.DEF) file is a text file containing one or more module statements that describe various attributes of a DLL. If you are not using the __declspec(dllexport) keyword to export the DLL’s functions, then the DLL requires a .DEF file. A minimal .DEF file must contain the following module-definition statements: The first statement in the file must be the LIBRARY statement. This statement identifies the .DEF file as belonging to a DLL. The LIBRARY statement is followed by the name of the DLL. The linker places this name in the DLL's import library. The EXPORTS statement lists the names and, optionally, the ordinal values of the functions exported by the DLL. You assign the function an ordinal value by following the function’s name with an at sign (@) and a number. When you specify ordinal values, they must be in the range 1 through N, where N is the number of functions exported by the DLL. If you wish to export functions by ordinal, see Export Functions From a DLL By Ordinal Rather Than By Name as well as this topic. Although not required, typically a .DEF file also contains a DESCRIPTION statement that describes the purpose of the DLL. For example, a DLL that contains the code to implement a binary search tree might look like the following: LIBRARY BTREE DESCRIPTION "Implements a binary tree." EXPORTS Insert @1 Delete @2 Member @3 Min @4 If you use AppWizard to create an MFC DLL, AppWizard creates a skeleton .DEF file for you and automatically adds it to your project. Add the names of the functions to be exported to this file. For non-MFC DLLs, you must create the .DEF file yourself and add it to your project. If you are exporting functions in a C++ file, you will have to either place the decorated names in the .DEF file or define your exported functions with standard C linkage by using extern “C”. If you need to place the decorated names in the .DEF file, you can obtain them by using the tool DUMPBIN or by using the linker switch /MAP. Note that the decorated names produced by the compiler are compiler specific. If you place the decorated names produced by the Visual C++ compiler into a .DEF file, applications that link to your DLL must also be built using the same version of Visual C++ so that the decorated names in the calling application match the exported names in the DLL’s .DEF file. If you are building an extension DLL, and exporting using a .DEF file, place the following code at the beginning and end of your header files that contain the exported classes: #undef AFX_DATA #define AFX_DATA AFX_EXT_DATA // <body of your header file> #undef AFX_DATA #define AFX_DATA These lines ensure that MFC variables that are used internally or that are added to your classes are exported (or imported) from your extension DLL. For example, when deriving a class using DECLARE_DYNAMIC, the macro expands to add a CRuntimeClass member variable to your class. Leaving out these four lines may cause your DLL to compile or link incorrectly or cause an error when the client application links to the DLL. When building the DLL, the linker uses the .DEF file to create an export (.EXP) file and an import library (.LIB) file. The linker then uses the export file to build the .DLL file. Executables that implicitly link to the DLL link to the import library when they are built. Note that MFC itself uses .DEF files to export functions and classes from the MFCx0.DLL. What do you want to do? Export from a DLL using __declspec(dllexport) Export and import using AFX_EXT_CLASS Export C++ functions for use in C-language executables Export C functions for use in C or C++-language executables Determine which exporting method to use Import into an application using __declspec(dllimport) Prepare the MFC DLL for use by an application, or Prepare the Win32 DLL for use by an application What do you want to know more about? .DEF files Rules for module-definition statements Decorated names Importing and exporting inline functions Mutual imports

buyong 2014-04-14