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