$ 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 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... I find the end of http://anadoxin.org/blog/control-over-symbol-exports-in-gcc.html interesting though it's the inverse problem
2017-11-06 19:08 GMT+01:00 Ben Coman btc@openinworld.com:
$ 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 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
And maybe another good hit https://www.gnu.org/software/gnulib/manual/html_node/Exported-Symbols-of-Sha...
2017-11-06 19:29 GMT+01:00 Nicolas Cellier < nicolas.cellier.aka.nice@gmail.com>:
Maybe google gcc export all symbols a workaround would be -Wl,--export-all-symbols or something like that... I find the end of http://anadoxin.org/blog/control-over-symbol-exports- in-gcc.html interesting though it's the inverse problem
2017-11-06 19:08 GMT+01:00 Ben Coman btc@openinworld.com:
$ 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 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
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 < nicolas.cellier.aka.nice@gmail.com> wrote:
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 <nicolas.cellier.aka.nice@ gmail.com>:
Maybe google gcc export all symbols a workaround would be -Wl,--export-all-symbols or something like that... I find the end of http://anadoxin.org/blog/contr ol-over-symbol-exports-in-gcc.html interesting though it's the inverse problem
2017-11-06 19:08 GMT+01:00 Ben Coman btc@openinworld.com:
$ 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 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
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
vm-dev@lists.squeakfoundation.org