[Off-Topic] linking exported symbols into shared lib

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[Off-Topic] linking exported symbols into shared lib

Ben Coman
 

$ 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




Reply | Threaded
Open this post in threaded view
|

Re: [Off-Topic] linking exported symbols into shared lib

Nicolas Cellier
 
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 <[hidden email]>:
 

$ 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






Reply | Threaded
Open this post in threaded view
|

Re: [Off-Topic] linking exported symbols into shared lib

Ben Coman
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
Reply | Threaded
Open this post in threaded view
|

Re: [Off-Topic] linking exported symbols into shared lib

Nicolas Cellier
In reply to this post by Nicolas Cellier
 

2017-11-06 19:29 GMT+01:00 Nicolas Cellier <[hidden email]>:
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 <[hidden email]>:
 

$ 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







Reply | Threaded
Open this post in threaded view
|

Re: [Off-Topic] linking exported symbols into shared lib

Ben Coman
 
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:
 

2017-11-06 19:29 GMT+01:00 Nicolas Cellier <[hidden email]>:
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 <[hidden email]>:
 

$ 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