Ok, I’m working on getting rid of Transfer engine (it’s for sharing in this case).
The linking is not necessary. The python library in use will function without any of those. That’s why I’m trying to do an
'__provides_exclude;^_imagingtk.cpython-38-arm-linux-gnueabihf.so ’ /
and or
‘__requires_exclude’…
The compiled parts _imagingmorph and co work fine without the ```
libfreetype|libjpeg|libopenjp2|libtiff|libfreetype etc.
I should add, the python library works fine without the linked libs but will not work without the compiled libs (_imagingtk.cpython-38-arm-linux-gnueabihf.so)
I see. Then you should try change the build so that it does not link against those libraries. The provides/requires macros won’t help with that.
Ok, that is not the information contained in the FAQ. I was following:
I got the following reject reason: “ERROR [libFooBar.so.1] Cannot require shared library: ‘libFooBar.so.1’”. What can I do?
You most likely have your own libraries packaged to the RPM. Harbour RPM packages should not require any library which is not allowed (see allowed libraries below), also not own provided libraries. To exclude libraries from the ‘Requires section’, which you ship with your RPM, please add the following to the .spec file between the “# >> macros” and “# << macros”. You have to specify each library name!
But I should be able to get rid of the linking, it just makes maintenance a lot more work.
The FAQ should be more clear that the macros won’t help or more clearly elaborate under what conditions the macros will help. Reading the red hat docs makes it clear it’s a bit voodoo as it is.
But that’s a different error the FAQ is talking about. At least I’m not getting “Cannot require shared library” but “Cannot link to shared library”.
How are you ‘getting that’?
On building 3.4->Release->Manual rpm:
First part:
Libraries
=========
INFO [/usr/share/harbour-simplecrop/lib/PIL/_imagingtk.cpython-38-arm-linux-gnueabihf.so] Private shared library shipped
INFO [/usr/share/harbour-simplecrop/lib/PIL/_imagingmorph.cpython-38-arm-linux-gnueabihf.so] Private shared library shipped
INFO [/usr/share/harbour-simplecrop/lib/PIL/_imagingmath.cpython-38-arm-linux-gnueabihf.so] Private shared library shipped
INFO [/usr/share/harbour-simplecrop/lib/PIL/_imagingft.cpython-38-arm-linux-gnueabihf.so] Private shared library shipped
ERROR [/usr/share/harbour-simplecrop/lib/PIL/_imagingft.cpython-38-arm-linux-gnueabihf.so] Cannot link to shared library: libfreetype.so.6
INFO [/usr/share/harbour-simplecrop/lib/PIL/_imagingft.cpython-38-arm-linux-gnueabihf.so] Please see our FAQ here: https://harbour.jolla.com/faq#Shared_Libraries
INFO [/usr/share/harbour-simplecrop/lib/PIL/_imaging.cpython-38-arm-linux-gnueabihf.so] Private shared library shipped
ERROR [/usr/share/harbour-simplecrop/lib/PIL/_imaging.cpython-38-arm-linux-gnueabihf.so] Cannot link to shared library: libjpeg.so.62
ERROR [/usr/share/harbour-simplecrop/lib/PIL/_imaging.cpython-38-arm-linux-gnueabihf.so] Cannot link to shared library: libopenjp2.so.7
ERROR [/usr/share/harbour-simplecrop/lib/PIL/_imaging.cpython-38-arm-linux-gnueabihf.so] Cannot link to shared library: libtiff.so.5
INFO [/usr/share/harbour-simplecrop/lib/PIL/_imaging.cpython-38-arm-linux-gnueabihf.so] Please see our FAQ here: https://harbour.jolla.com/faq#Shared_Libraries
And at the end:
Requires
========
ERROR [libfreetype.so.6] Cannot require shared library: 'libfreetype.so.6'
ERROR [libjpeg.so.62] Cannot require shared library: 'libjpeg.so.62'
ERROR [libjpeg.so.62(LIBJPEG_6.2)] Cannot require shared library: 'libjpeg.so.62(LIBJPEG_6.2)'
ERROR [libopenjp2.so.7] Cannot require shared library: 'libopenjp2.so.7'
ERROR [libtiff.so.5] Cannot require shared library: 'libtiff.so.5'
INFO [harbour-simplecrop] Please see our FAQ here: https://harbour.jolla.com/faq#2.6.0 how to use '__provides_exclude_from' and '__requires_exclude' .spec file to avoid that
FAILED
using requires and provides macros i can change the output but not get rid both. I assume the linking will always die, though that’s a bit strict.
the way I read the faq is remove ‘requires’ and the linking problem should ‘go away’. That doesn’t seem to be the case which I can understand.
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:
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.
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 
Marty’s 1a solution works like a charm! Thanks for the tips!
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.