poppler: port does not create static libs

[potterpg]

This port does not seem to create Static libaries? - Mac M1 +universal variant.

Seems to create the dylibs ok, but I don't see what I need, the static libs...

I did deactivate boost, if relevant, but otherwise compiled/downloaded just fine...

Am I correct in thinking that static libs normally get generated as well for mac ports?

[mascguy (Christopher Nielsen)]

Am I correct in thinking that static libs normally get generated as well for mac ports?

No, it depends on the port. Some provide both static and dynamic libs, others only provide dylibs. (And there are probably a few ports that only provide static libs, though I suspect there aren't many.)

Can you elaborate on your use-case? And do you absolutely need a static lib...?

[jmroot (Joshua Root)]

You can view the installed file lists at ​https://ports.macports.org/port/poppler/details/, which shows only dylibs are installed regardless of architecture.

[potterpg]

mascguy
Can you elaborate on your use-case? And do you absolutely need a static lib...?

Hi, yes, I have a solution within which I use a number of utility libraries to do certain tasks... Some simple like file zipping, some for modifying PDFs, and others for modifying images.

In the dev environment that I use for that, I need to create a specifically formatted object to do those tasks, and it is far easier to create a single object with all requirements within it, not needing any external dylibs, or DLLs on windows.

This way if I make a change, I can download the single file, for the specific platform, and know that it will work without fail.

Previously I did this on an intel Mac after creating the static lib for that. I don't recall if I used this amazing macports for that, or did it the hard way, and compiled it myself.

So, for me, the answer is yes, I really need static libs... If some kind person can make the macports version work, that will be great...

Otherwise I will have to try plan B, and just try to compile it myself from source code.

[ryandesign (Ryan Carsten Schmidt)]

It used to be the case that MacPorts ports would generally install both static and dynamic libs. The reason for this was that most ports built their libraries using ​autotools (autoconf, automake, libtool), and the default for that toolchain is to build and install both static (--enable-static) and dynamic (--enable-shared) libs.

However in the decades since then many projects have switched to other build systems, for better or for worse. Poppler now uses ​CMake. (The poppler ​cmake build system was introduced in 2008 alongside autotools for many years before the ​autotools build system was removed in 2017.) CMake only allows you to build either static (-DBUILD_SHARED_LIBS=OFF) or dynamic (-DBUILD_SHARED_LIBS=ON) libs but not both at the same time (unless the project has made special provisions for that by bypassing cmake's library creation code and writing its own, which does not seem to be the case for poppler; I know of only one cmake-using project that has done that).

So unfortunately without a massive restructuring of the cmake portgroup to accommodate automatically performing multiple builds (one for static and one for dynamic), we cannot offer a port of poppler (or most other cmake-using software) that provides both static and dynamic libs. We must choose one or the other, and we must choose dynamic libs. You could file a feature request with the developers of cmake asking them to make it easy to build both static and dynamic libs, if an issue has not already been filed about this.

[potterpg]

Ok, thanks Ryan.

Clearly something that isn't going to happen anytime soon, thanks for explaining why.

I'll except your answer, although in the back of my mind I'm sure in other cmake projects I've seen options to build both, but since I tend to try to get static libs, I might not of actually seen whether it built both, even though the option seems to be in there...

Since I will have to go through the source code route to get my static library, I'll find out I guess.

[mascguy (Christopher Nielsen)]

Replying to potterpg:

I'll except your answer, although in the back of my mind I'm sure in other cmake projects I've seen options to build both, but since I tend to try to get static libs, I might not of actually seen whether it built both, even though the option seems to be in there...

Since I will have to go through the source code route to get my static library, I'll find out I guess.

Depending on upstream's project, it might be as simple as adding a few additional lines to the appropriate CMakeLists.txt. (And sometimes it's as simple as adding an additional line, if you don't mind using the same basename for both libs.)

However, each case is highly-specific to the project in question. Which dovetails with Ryan's earlier comment, re: why we can't easily implement it via the cmake portgroup.

This isn't desirable for the port in-general, so it's not something we'd want to add. But just letting you know that it's typically not difficult.