Correct me if I am wrong, but mostly the simplest way is to remove the corresponding -devel packages.
Umm, which do you mean?
All of the c libs:
lib/PIL/_imaging.cpython-38-arm-linux-gnueabihf.so
and co. ar not ‘optional’.
I was thinking the required libraries, like libjpeg.so and others
If I am wrong in this context, ignore me 
Ah, you mean something like?
# - '__requires_exclude;^libfreetype|libjpeg|libopenjp2|libtiff|libfreetype.*$'
# - '__provides_exclude;^libfreetype|libjpeg|libopenjp2|libtiff|libfreetype.*$'
I did try that but not successfully. Probably screwed up the regex.
I only have experience with the Platform SDK with 4.0.1.48, I think you are using the Application SDK.
I mean running stuff like this:
sb2 -t SailfishOS-armv7hl -m sdk-install -R
rpm -e libjpeg-turbo-devel
With more standard linux distro’s it is common to have a clean build system and only have packages installed that are part of the BuildRequires of the package you want to build. It might be good to clean up the build system before building a package.
But again, I am quite unfamiliar with the Application SDK and best practices when it comes to Sailfish.
Personally I prefer sfdk over Qt Creator for this kind of stuff (i.e. when I don’t need to actually edit the code):
sfdk check -s harbour RPMS/harbour-simplecrop-1.6.4-1.6.4.armv7hl.rpm
But the result should be the same as what you get when building with Qt Creator.
I get the same linking errors as you do, but on the “Requires” section, I get:
Requires
========
PASSED
@marcelpol is probably on the right track, removing the devel packages from the build target might be the easiest way:
$ sfdk tools exec SailfishOS-3.4.0.24-armvhl
[SailfishOS-3.4.0.24-armv7hl] ~ # rpm -e --nodeps freetype-devel libtiff-devel openjpeg-devel libjpeg-turbo-devel
Please note that this will kind of break your build target, so you might want to install the packages back after building your package:
$ sfdk tools exec SailfishOS-3.4.0.24-armvhl
[SailfishOS-3.4.0.24-armv7hl] ~ # zypper in freetype-devel libtiff-devel openjpeg-devel libjpeg-turbo-devel
I see two issues reported by the validator:
- Cannot link to a shared library
- Cannot require a shared library
First of all you need to fix issue no. 1. You have two options I think:
1A. Bundle all the disallowed dependencies (libfreetype.so.6, libjpeg.so.62, libopenjp2.so.7, …) with your app and ensure that the libraries that link them have RPATH set so that they can locate them under your app data directory (you do that already). The validator will notice this and stop complaining.
1B. Rebuild the python PIL library in a way that it does not contain these dependencies (assuming that what you wrote before “the python library works fine without the linked libs” applies also in the sense that your app works fine without PIL being able to use those libs).
I would choose 1A. I don’t know how do you build PIL, so depending on that there may be a more clever option, but simply adding BuildRequires for the required libraries and then copying them from system directories in your %install section should work well:
# >> install post
install -t %{buildroot}/%{_datadir}/%{name}/lib/ \
/usr/lib/libjpeg.so.62 \
/usr/lib/libopenjp2.so.7 \
/usr/lib/libtiff.so.5 \
/usr/lib/libfreetype.so.6 \
/usr/lib/libwebpdemux.so.2 \
/usr/lib/libwebpmux.so.3 \
/usr/lib/libwebp.so.7
# << install post
After that, you can get rid of the – now false – package dependencies by adding this line to your .yaml:
- '__provides_exclude_from;^%{_datadir}/%{name}/lib/.*\\.so\\>'
- '__requires_exclude_from;^%{_datadir}/%{name}/lib/.*\\.so\\>'
PS: sdk-deploy-rpm is not the only package deployed when a device is being added under the IDE. Check that the patterns-sailfish-sdk-client-tools package is installed to be sure that the device works well with the SDK.
1 Like
I’m using the Application SDK (4.0.1.48). Since I’m running all the usual debugging from within the QT designer, I’m also doing the deployment testing and generating rps from within. So, the environment is the one supplied by Jolla.
The libs I’m including are snapshot releases, in this case from the pillow library. The c libs that are included are left as is since that ‘just works’ even if there are: 1. unused functions that require, 2. unused linked libs.
Yup. That’s lazy, but means I don’t make errors compiling third party libraries. I am looking at that since I’ve already got most dependancies into application context. But that becomes hard to keep up with if you maintain more than one app.
1A is the right solution I believe!
I need to get from about 12 versions uptodate so doing testing with each iteration and having to compile everything would really slow me down.
Thanks! This is great! That means 3 more apps coming to a Jolla store near you (errr. soon 
1 Like
Marty’s 1a solution works like a charm! Thanks for the tips!
1 Like
Hi, I just wanted to let you know that I literarlly copied your code in situ (the provides_exclude between macros) and it ‘just worked’ ™.
The only thing that doesn’t work is building for 64bit arch. I’m still looking to see why that is. i486 and arm builds are complete and can be used (tested on 2 arm phones and by ssh on the 486 emulator).
The main reason is that you shouldn’t hardcode ‘/usr/lib’, but use ‘%{_libdir}’ instead. Then there’s another issue with the install line, you should have also the ‘-D’ parameter there. All in all, the install post should read like this:
# >> install post
install -D -t %{buildroot}/%{_datadir}/%{name}/lib/ \
%{_libdir}/libjpeg.so.62 \
%{_libdir}/libopenjp2.so.7 \
%{_libdir}/libtiff.so.5 \
%{_libdir}/libfreetype.so.6 \
%{_libdir}/libwebpdemux.so.2 \
%{_libdir}/libwebpmux.so.3 \
%{_libdir}/libwebp.so.7
# << install post
Ah, of course! That does get me a lot further and is cleaner for the other builds (tested arm 32 and x86). I get another error which I think has to do with the libs themselves:
ERROR [/usr/share/harbour-simplecrop/lib/libjpeg.so.62] Cannot link to shared library: ld-linux-aarch64.so.1
But that’s very probably because the libraries aren’t 64 bit as I just noticed. I’m going to need to build the dependencies.
Brings up the question why it works on aa64 machines. Well, maybe the users just haven’t tested yet.
I should be able to test these on the Yolla phone though. Sigh. I’ve been deploying/running armv7 and not aarch64 out of habit (Jolla phone/Fairphone2 being my other targets). So, we know the armv7 32 bit builds run well on aarch64
Damn it. So, pypi for aarch64 ships the library depends! That’s nice. Bit it doesn’t for arm32. Sigh. And I’m just up to 7.2.0 (current ist 8.2.0). Uhg
It’s nice app though, so I’m happy to go the distance. And I haven’t done any QT stuff for ages.
You are not building against 3.4 targets are you?
Yes I am. i only have 3.4 devices. Just building a GS290 (same hardware as Vollaphone). I’ll try rebuilding with the proper PIL libs as soon as the other build is finished.
That’s what I thought. Like mentioned in the blog post, the aarch64 support in 3.4 was experimental and not aimed for harbour submissions yet. Please use the 4.0.1 targets for your aarch64 builds.
Ach, thanks! But I probably won’t be able to test those since I’m running 3.4 an the Volla (and now also a GS290! )
I’m revisiting this now since I’m trying to build the libraries properly and I wondered if there is any documentation about building python stuff in a Sailfish SDK context? In principle, it’s probably a matter of building a subdirs project and added build steps to execute the python build : python3 setup.py sdist --format=gztar or so?
I wonder if you checked out Python Packaging Guidelines :: Fedora Docs and some examples for packaging. Something like Tree - rpms/python-requests - src.fedoraproject.org