scap-workbench-1.1.4-2.fc26.x86_64 package requires libpcre.so.1()(64bit). This is because /usr/bin/scap-workbench links to it: $ scanelf -n usr/bin/scap-workbench TYPE NEEDED FILE ET_DYN libQtXmlPatterns.so.4,libQtGui.so.4,libQtCore.so.4,libopenscap.so.8,libxslt.so.1,libxml2.so.2,libz.so.1,libdl.so.2,libm.so.6,libpcre.so.1,libstdc++.so.6,libgcc_s.so.1,libc.so.6 usr/bin/scap-workbench But it does use functions from the library at all: $ nm -D usr/bin/scap-workbench | grep pcre I think there as a useless -lpcre passed to linker when building /usr/bin/scap-workbench executable. Please fix the build script not to do so.
A typo: But it does _not_ use functions from the library at all.
This bug appears to have been reported against 'rawhide' during the Fedora 26 development cycle. Changing version to '26'.
https://github.com/OpenSCAP/openscap/blob/maint-1.2/libopenscap.pc.in I am not 100% sure why it's in the OpenSCAP pkgconfig file but at this point we would break apps by changing it in a maintenance branch. Unless something is horribly wrong we shouldn't require pcre in the public ABI.
This is still issue in Fedora 27 (scap-workbench-1.1.5-1.fc27.x86_64). Please fix it there.
(In reply to Petr Pisar from comment #4) > This is still issue in Fedora 27 (scap-workbench-1.1.5-1.fc27.x86_64). > Please fix it there. Is it really an issue? Can you please explain your use-case and how it would be affected if libpcre was not in the pkg-config file mentioned above? Seems like a nitpick that has absolutely no effect in the real world to me. (libpcre will have to be installed anyway because scap-workbench depends on openscap which depends on libpcre, same with libxslt, ..)
To make it clearer, this is the reason why all these extra libs get linked: $ pkg-config --libs libopenscap -lopenscap -lxslt -lz -llzma -ldl -lm -lxml2 -lpcre Solving it would involve removing the "Requires" statement from the pc file which has unwanted consequences. Either way, this is not an issue in scap-workbench. If it is an issue at all (and I have doubts) it's an issue in openscap.
I see. Then it's a bug in openscap-devel-1.2.14-2.fc27.x86_64. The issue is an application linking against libopenscap library links to unnecessary pcre library. This creates unnecessary build and run-time dependency on a RPM package, it delays execution due to loading pcre library, it enlarges attack surface because each process gets pcre library code into its execution space and it increases maintenance cost when bumping pcre library soname. Moreover pcre is dead and all projects should migrate to pcre2. I grepped openscap-devel header files and none of them includes pcre headers, I cannot see any reason why pkgconf --libs libopenscap should return -lpcre. Maybe you could explain what are the "unwanted consequences". Reassigning to openscap.
https://github.com/OpenSCAP/openscap/pull/796
Ahhh. So the issue is that libpcre.so should definitely not be there, libpcre2.so if anything should be there. So I looked into this and we are using pcre1 in libopenscap. Before we go ahead with this we should migrate to pcre2.
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle. Changing version to '27'.
Patches available: https://github.com/OpenSCAP/openscap/pull/803 https://github.com/OpenSCAP/openscap/pull/796 This will be fixed in the next upstream release of OpenSCAP 1.2.15.