How to compile as a dynamic link library

[nihao2015]

Hi, I know how to compile PDF-Writer as a linux static library(.a)， now I want to compile it as a dynamic link library on linux(.so) and how to do it? thanks!

[galkahana]

check out cmake documentation. also note that note below: https://github.com/galkahana/PDF-Writer/wiki/Building-and-running-samples#special-options-with-cmake

[gnat42]

I couldn't figure it out either so modified the PDFWriter/CMakeLists.txt

diff --git a/PDFWriter/CMakeLists.txt b/PDFWriter/CMakeLists.txt
index 137f841..5f64371 100644
--- a/PDFWriter/CMakeLists.txt
+++ b/PDFWriter/CMakeLists.txt
@@ -34,7 +34,7 @@ endif(NOT PDFHUMMUS_NO_PNG)

-add_library (PDFWriter 
+add_library (PDFWriter SHARED
 #sources
 AbstractContentContext.cpp
 AbstractWrittenFont.cpp

Wasn't sure of any other way to do it...

[samkots]

I tried the same. I was able to create a DLL, but it doesn't create a .lib file as nothing is getting exported from the DLL. I found that none of the functions are marked with export macros. So how the functions will be exported from the DLL?

[galkahana]

i think this should help you get there: https://stackoverflow.com/questions/225432/export-all-symbols-when-creating-a-dll

short one - yes, no dll exports in code...so you will need to use .def files. and it might be that you can modify the cmake setup to help you with this.

[samkots]

Thanks for your quick response.. Yes, actually I was thinking of writing a .def file.. Yes I have modified cmake setup and have generated a DLL. Just that it doesn't export anything. Thanks for the link. It will be helpful. Have you compiled it as a DLL that way?

Also I was wondering why there are no export macros. I know its a lot or work, but is there any plan? If not, I am thinking of doing it in my free time. Will that be acceptable as a pull request?

[galkahana]

@samkots never tried it. Exporting hummus as DLL on windows is too much effort, with them exporting macros (no need on mac/linux for instance, in case you're creating a shared lib), so i just don't. when i got the code right there, it's really not required. When using DLL's it's normally only of existing system dlls or products (e.g. excel, acrobat) that i don't have the source of. As for PR, export macros is good (as long as they are x platform), making the cmake create def files so the source code is clean and i dont have to support this going forward - is better.

[samkots]

Thanks to the link in your previous message, I was led here. I was able to create a DLL on Windows with this command: cmake -DCMAKE_WINDOWS_EXPORT_ALL_SYMBOLS=TRUE -DBUILD_SHARED_LIBS=TRUE .. and on Linux with this command: cmake -DBUILD_SHARED_LIBS=TRUE

I had to do the following changes to the CMake setup:

In LibPng\CMakeLists.txt append following line: target_link_libraries(LibPng PRIVATE ${ZLIB_LDFLAGS})

In LibTiff\CMakeLists.txt append following line: target_link_libraries(LibTiff PRIVATE ${ZLIB_LDFLAGS})

In PDFWriter\CMakeLists.txt append following line: target_link_libraries(PDFWriter ${LIBPNG_LDFLAGS})

It also passed all the test cases on both Linux & Windows.

Thanks a lot! :)

[samkots]

Regarding export macros, yes that's a big effort. My concern was just about the unnecessary symbols getting exported(if any). Even on Linux, I use the -fvisibility=hidden flag which, just like Windows, hides all the symbols by default and then I put macros only on the functions that I want to export. This gives us control over what we are exporting. Anyways, that's just my opinion.. Thanks :)