Using libpoppler in harbour application

Applications C++
#1

I’ve developed an application which is using libpoppler-qt5 to read and render pdf documents. However, it cannot be published in jolla store, due to this requirements.

What would be the best way to publish in jolla store:

  • statically recompile libpoppler-qt5, and include it in the binary. I fear that libpoppler itself has a lot of dependencies, and it may be a lot of work
  • copy the shared object from the sdk in the rpm (same issue)
  • another ideas ?

How do usually application do if they rely on third party libraries which are somewhat guaranted to be available on the system ?

1 Like
What APIs are missing from Harbour?
How to include shared library in my .rpm?
#2

Usually bundling dependencies not allowed in harbour with your application is the recommended solution. I thin 1 and 2 both would work. You need to bundle all dependencies, that are not allowed, with your app. If poppler-qt5 has such dependencies, you will need to include those too. If its dependencies are allowed, you don’t need to. It looks like poppler-qt5 doesn’t actually have a lot of disallowed dependencies, but I’m sure there are others, who already use that lib and can give more information regarding that.

1 Like
#3

Well, what are you using it for?
Is it a hard or soft (optional added feature) dependency?
My app SeaPrint uses pdftoppm as an optional dependency, running inside a QProcess.

AFAIK MuPDF builds much more cleanly and contains all non-trivial dependencies as submodules, but i’m not sure it helps you.

1 Like
#4

It’s a hard dependency, the app basically just annotates a source pdf document. I could get rid of it by recreating the whole document inside the app, but that would be overkill.

I’ll take a look at how to rebuild libpoppler. Thanks for your answers !

1 Like
#5

You don’t need to actually build it. You can just copy to a RPATH of your program the required library from the SDK into your RPM.

Not necessary a perfect way to do this, but you can have a look to Mæp spec file: https://github.com/dcaliste/maep-qt/blob/master/rpm/maep-qt.spec I’m putting in the RPM things like libsoup, libcairo… I’m having also this line in the maep.pro file:
# This part is to circumvent harbour limitations.
QMAKE_RPATHDIR = $$DEPLOYMENT_PATH/lib
where DEPLOYMENT_PATH is a simple variable pointing to $$PREFIX/share/$$TARGET.

2 Likes
#6

Thanks a lot, it seems to work fine. The remaining issue is that the jolla-built libpoppler has some hardcoded path in them, which is also forbidden :confused: .

I’ll try to submit it that way, with a note to qa, let’s see if it passes. Otherwise i’ll try to rebuild poppler.

2 Likes
#7

I started trying to replicate this build process for SeaPrint, since Poppler is adamant that pdftoppm needs to remain useless for mixed-orientation files. But i’m unable to get it to build. It looks like the .so files referred are not available in the build docker container. Do i need to install them somehow?

When doing e.g. sfdk engine exec sudo zypper in freetype, the “already installed” error message says i486, so i guess that’s not how it it’s done…

Do i need to kill the .yaml file, and when doing so, is there something i should change with the .spec?

#8

You can have a look at https://github.com/Julien-Blanc-tgcm/LAttestation for a simple example. It does not use the yaml file, directly the .spec, iirc i had issues with the macros part which kept being overwritten. In all cases, check what is in the spec file, you need to have:

  • the macros
  • the build-requires
  • the install, with the correct .so versions (depends on the kit you’re using).

AFAIK you can use the .spec generated as the base, if you simply remove the yaml it will no longer be overwritten / regenerated.

I use qtcreator to compile (almost never call sfdk by hand), and i use the docker sdk. I’ve found docker run -it sailfish-os-build-engine /bin/sh to be of real help to inspect the content of the sdk (will run a shell inside the docker container). and find the correct versions. Won’t work if you use virtualbox, of course.

#9

Thanks!

So it seems i got most part down the right path, but today i learned sfdk engine exec ls /usr/lib/libpoppler* is different from sfdk engine exec /bin/bash followed by ls /usr/lib/libpoppler*.
How it is different remains a mystery :slight_smile:

The hint to check versions was also very helpful, not that it was surprising, but i had messed something up and needed a retake on that.

#10

How it is different remains a mystery

The answer is shell argument expansion -> sfdk engine exec ls /usr/lib/libpoppler* the * is expanded locally, which is likely to resolve to a file different than the one on the sdk, resulting in file not found. So it should be sfdk engine exec ls "/usr/lib/libpoppler*" (notice the quotes, they will prevent shell argument expansion), but even that is not sufficient. Contrary to common belief, ls does not support any pattern in its arguments: the patterns are expanded by the shell. You can verify this by running ls "/usr/lib/*" (again, notice the quotes) which should return file not found on a standard system.

#11

Hmm, i still get no hits with sfdk engine exec ls "/usr/lib/libpoppler*". It does make sense i need to escape local expansion though, good point, should have realized.

But it builds now, so no worries. Just found out that the tools i just duct-taped together does what i need quite well, and replicating it inside the application takes more than i expected… so maybe i should not bother at this point in time. But it is good to know this is one way out of the hole i have dug. :slight_smile:

#12

With that command you are trying to install the package to the build engine itself, and not to the build target. The correct way to get the required packages installed to the build target is to use the BuildRequires definitions in the spec file.

1 Like