fpdfview.o:0000000000000000 T FPDF_InitLibrary fpdfview.o:0000000000000000 T FPDF_InitLibraryWithConfig fpdfview.o:0000000000000000 t FPDF_InitLibraryWithConfig.part.47 IIUC, the capital "T" means the "FPDF_InitLibrary" symbol is exported and available for another program to link against. Browsing around, object files are composed into a shared library like this... $ g++ -fPIC -shared -o libmypdf.so fpdfview.o but now the "FPDF_InitLibrary" symbol shows as internal and I can't link against it. $ nm -A libmypdf.so | grep FPDF_Init libmypdf.so:0000000000003e60 t FPDF_InitLibrary libmypdf.so:0000000000003e80 t FPDF_InitLibraryWithConfig libmypdf.so:00000000000031f0 t FPDF_InitLibraryWithConfig.part.47 Here is my makefile... INC_DIR= -I ./public LIB_DIR= -L ./out STD_LIBS= -lpthread -lm -lc -lstdc++ PDF_LIBS= -lmypdfium default: gcc -o first first.c ${INC_DIR} ${LIB_DIR} ${PDF_LIBS} ${STD_LIBS} So I know it finds the library, since if I change its name the linker complains it can't find the file. I don't think the following adds useful extra info, but for completeness... The header file fpdfview.h has... #if defined(_WIN32) && defined(FPDFSDK_EXPORTS) // On Windows system, functions are exported in a DLL #define FPDF_EXPORT __declspec(dllexport) #define FPDF_CALLCONV __stdcall #else #define FPDF_EXPORT #define FPDF_CALLCONV #endif #ifdef __cplusplus extern "C" { #endif FPDF_EXPORT void FPDF_CALLCONV FPDF_InitLibrary(); #ifdef __cplusplus } #endif |
Maybe google gcc export all symbols a workaround would be -Wl,--export-all-symbols or something like that...2017-11-06 19:08 GMT+01:00 Ben Coman <[hidden email]>:
|
In reply to this post by Ben Coman
Whoops, I was only half way through composing that.
I hope you don't mind my seeking on expertise here in C library linking. I've exhausted my search-fu and this is the place people know me. I hope my question is low level and generic enough that what I learn could be useful later working on opensmalltalk-vm. PDFium is a component of Chromium/Chrome for rendering PDFS. By default it only builds a static library, but I found a configuration option to builds shared library, but it seems it misses some symbols. Now the object file remain available and I found the required symbol exported from them. For example... $ nm -A fpdfview.o | grep FPDF_Init fpdfview.o:0000000000000000 T FPDF_InitLibrary fpdfview.o:0000000000000000 T FPDF_InitLibraryWithConfig fpdfview.o:0000000000000000 t FPDF_InitLibraryWithConfig.part.47 IIUC, the capital "T" means the "FPDF_InitLibrary" symbol is exported and available for another program to link against. Browsing the web, it seems like object files can be composed into a shared library like this... $ gcc -fPIC -shared -o libmypdf.so fpdfview.o but I end up with the "FPDF_InitLibrary" hidden as an internal symbol... $ nm -A libmypdf.so | grep FPDF_Init libmypdf.so:0000000000003e60 t FPDF_InitLibrary libmypdf.so:0000000000003e80 t FPDF_InitLibraryWithConfig libmypdf.so:00000000000031f0 t FPDF_InitLibraryWithConfig.part.47 so I can't link my test code against it Here is my makefile... INC_DIR= -I ./public LIB_DIR= -L ./out STD_LIBS= -lpthread -lm -lc -lstdc++ PDF_LIBS= -lmypdfium default: gcc -o test test.c ${INC_DIR} ${LIB_DIR} ${PDF_LIBS} ${STD_LIBS} Now I know the library is found, since if I change its name the linker complains it can't find the file. I don't think the following adds useful extra info, but for completeness... The header file fpdfview.h has... #if defined(_WIN32) && defined(FPDFSDK_EXPORTS) // On Windows system, functions are exported in a DLL #define FPDF_EXPORT __declspec(dllexport) #define FPDF_CALLCONV __stdcall #else #define FPDF_EXPORT #define FPDF_CALLCONV #endif #ifdef __cplusplus extern "C" { #endif FPDF_EXPORT void FPDF_CALLCONV FPDF_InitLibrary(); #ifdef __cplusplus } #endif cheers -ben |
In reply to this post by Nicolas Cellier
And maybe another good hit https://www.gnu.org/software/gnulib/manual/html_node/Exported-Symbols-of-Shared-Libraries.html 2017-11-06 19:29 GMT+01:00 Nicolas Cellier <[hidden email]>:
|
Thanks Nicolas. I'm not quite there yet, but that has set me down a promising path.
cheers -ben On Tue, Nov 7, 2017 at 2:33 AM, Nicolas Cellier <[hidden email]> wrote:
|
Free forum by Nabble | Edit this page |