DevHeads.net

Is it possible to manually insert shared library deps in an RPM?

Hi,

gcc and cross-gcc currently dynamically load the isl-0.14 shared library -
which means that rpm-build doesn't automagically detect a:

libisl.so.13()(64bit)

but, rather, the gcc binary rpm must include a:

Requires: isl = %{isl_version}

clause.

Is it possible to instead do something like:

Requires: libisl.so.13()(64bit)

(though this doesn't work because it complains about an illegal char) so that
it is pegged to the major version of the library rather than the specific isl
version?

Thanks,
David

Comments

Re: Is it possible to manually insert shared library deps in an

By David Howells at 02/04/2017 - 19:34

That was my suggestion too, but Jakub doesn't like that idea.

David

Re: Is it possible to manually insert shared library deps in an

By Kevin Kofler at 02/04/2017 - 17:10

David Howells wrote:
Maybe you actually want to patch the code to just link the library instead
of dlopening it? Dlopening libraries is unfortunately a common disease in
upstream projects. There are a few valid reasons to dlopen a library, but
none seem to apply here, at least not for us in Fedora:

* You want to make the library optional. This is clearly not the case, or
you would not be adding a Requires to the package.

* You want to support different soversions of the library for some reason.
This is typically not the case in distribution packages. It also needs
special code to look up the correct soname or it will not work properly.
(A common disease in upstream projects is attempting to load the
unversioned .so, which does of course NOT work on real-world distributions
because the unversioned symlink is in the -devel package where it
belongs.) I also do not see this being the case here.

So I think that the library should really be linked, not dlopened.

Kevin Kofler

Re: Is it possible to manually insert shared library deps in an

By David Howells at 02/03/2017 - 12:18

Okay, creating a script:

#!/bin/sh
if [ -x /usr/lib/rpm/redhat/find-requires ] ; then
FINDREQ=/usr/lib/rpm/redhat/find-requires
else
FINDREQ=/usr/lib/rpm/find-requires
fi
$FINDREQ $*
case `uname -m` in
*64)
echo 'libisl.so.15()(64bit)'
;;
*)
echo 'libisl.so.15()'
;;
esac

gives me the following:

warthog>rpm -qpR x86_64/gcc-x86_64-linux-gnu-6.3.1-1.fc26.x86_64.rpm
...
libisl.so.15()(64bit)
...

which seems more or less what I was looking for. Deciding whether or not I
want to include the "(64bit)" flag is another issue to be solved.

David

Re: Is it possible to manually insert shared library deps in an

By David Howells at 02/06/2017 - 06:06

Should "(64bits)" be appended on, say, ia64 where there is no 32-bit
userspace?

David

Re: Is it possible to manually insert shared library deps in an

By Panu Matilainen at 02/06/2017 - 06:15

On 02/06/2017 12:06 PM, David Howells wrote:
ia64 doesn't exist anymore so what difference does it make?

IIRC the only 64bit arch not having (64bit) markers in their deps was
alpha which is even more dead than ia64 by now.

Re: Is it possible to manually insert shared library deps in an

By Panu Matilainen at 02/06/2017 - 06:18

On 02/06/2017 12:15 PM, Panu Matilainen wrote:
BTW, one way to avoid the whole (64bit) mess is to turn it into a file
dependency instead:

Requires: %{_libdir}/libisl.so.15

Re: Is it possible to manually insert shared library deps in an

By David Howells at 02/04/2017 - 19:32

That doesn't work. It complains about illegal characters.

David

Re: Is it possible to manually insert shared library deps in an

By David Howells at 02/06/2017 - 05:47

It works now, thanks. I'm not sure what I did before, but:

Requires: libisl.so.13()(64bit)

definitely did produce an error, but now no longer does.

David

Re: Is it possible to manually insert shared library deps in an

By Panu Matilainen at 02/06/2017 - 07:02

On 02/06/2017 11:47 AM, David Howells wrote:
You probably had some special unicode character there which looks like
an ascii character, or something like that. Parenthesis and full stops
are among the most common non-alphanumeric characters in dependencies.

Re: Is it possible to manually insert shared library deps in an

By Panu Matilainen at 02/05/2017 - 04:00

On 02/05/2017 01:32 AM, David Howells wrote:
Sure it works. It's copy-pasted from a spec I just built *just in case*
there's been some sort of wacko regression someplace, that's not the case.

Parentheses have always been a common part of rpm provides and requires,
if you're getting errors there's something else going on.
Feel free to point me to the spec that's giving you illegal character
errors from the above.

Re: Is it possible to manually insert shared library deps in an

By Panu Matilainen at 02/04/2017 - 07:21

On 02/03/2017 06:18 PM, David Howells wrote:
Eek. Please don't.

You're turning the whole dependency generator upside down into a
deprecated mode which has unwanted side-effects, just to insert one
dependency. Which you can just as well create in the spec directly,
something like

%if %{__isa_bits} == 64
Requires: libisl.so.15()(64bit)
%else
Requires: libisl.so.15()
%endif

...for a very simple example. And if you really want to do things with
the dependency generator, all you need to do is to override
%__elf_requires, not the entire thing.

Re: Is it possible to manually insert shared library deps in an

By David Howells at 02/03/2017 - 11:56

This scriptlet would seem to be inconsistent with the way find-requires works:

$FINDREQ $* | sed -e '/libbadreq.so/d'

but find-requires seems to require the filenames to be piped in rather than
passed on the command line.

David

Re: Is it possible to manually insert shared library deps in an

By Richard W.M. Jones at 02/04/2017 - 06:37

On Fri, Feb 03, 2017 at 03:56:40PM +0000, David Howells wrote:
IIRC about this stuff, the script has to be prepared to work both
ways.

You might be interested in looking at an example of a known working
depedency generator script:

$ rpm -ql supermin-devel
/usr/lib/rpm/fileattrs/supermin.attr
/usr/lib/rpm/supermin-find-requires

Rich.

Re: Is it possible to manually insert shared library deps in an

By David Howells at 02/03/2017 - 11:43

They bumped it somewhere between isl-0.14 (which gcc uses now) and isl-0.16.1
(which gcc wants to use).

David

Re: Is it possible to manually insert shared library deps in an

By Daniel P. Berrange at 02/03/2017 - 10:51

On Fri, Feb 03, 2017 at 02:45:08PM +0000, David Howells wrote:
The automatic requires are added based on output of an external program.
You can override which program is used in the spec file. So you could
provide a custom script which calls the original script, and then also
output the extra missing library requires

See the section "requires filtering"

<a href="https://fedoraproject.org/wiki/PackagingDrafts/FilteringAutomaticDependencies" title="https://fedoraproject.org/wiki/PackagingDrafts/FilteringAutomaticDependencies">https://fedoraproject.org/wiki/PackagingDrafts/FilteringAutomaticDepende...</a>

instead of filtering you'd be augmenting, but that's fine.

Regards,
Daniel

Re: Is it possible to manually insert shared library deps in an

By Jakub Jelinek at 02/03/2017 - 11:52

On Fri, Feb 03, 2017 at 02:51:28PM +0000, Daniel P. Berrange wrote:
Doesn't
%global _use_internal_dependency_generator 0
break the multilib coloring though? At least I vaguely remember it
did in the past.

Jakub

Re: Is it possible to manually insert shared library deps in an

By Panu Matilainen at 02/04/2017 - 07:06

On 02/03/2017 05:52 PM, Jakub Jelinek wrote:
Um, no it doesn't. Parenthesis are perfectly legal in rpm dependencies.

It used to, but no longer does as of rpm >= 4.12 or so. It does have
other unwanted side-effects though, and is deprecated and all.

That ancient draft would be best taken offline because it sends people
into the wrong direction armed with a sledgehammer they really don't
need for minor tweaking.

Re: Is it possible to manually insert shared library deps in an

By Stephen Gallagher at 02/03/2017 - 10:50

On 02/03/2017 09:45 AM, David Howells wrote:
What's wrong with doing:

Requires: isl%{?_isa} >= %{isl_version}

Other than you'll have to be aware and deal with any eventual soname bump, of
course.