Jerry Chappell a écrit:
Alain, packager uses the SONAME/NEEDED fields in the elf header to generate
the QPM:RequiresLibrary and QPM:ContainsLibrary tags, so you can do:
objdump -x libDataServer_API.so.3.1 | grep SONAME
objdump -x myapp | grep NEEDED
to make sure that the sonames are exact matches. From your description it
sounds like you will have something like:
SONAME libDataServer_API.so.3.1
NEEDED libDataServer_API.so.3.0
so that’s not a match, and the dependency check will fail in the installer.
Correct.
In fact I provide a library for which the SONAME is .so.3.1.
I want to install an application for which the NEEDED is .so.3.0
If (and only if) your application runs perfectly with the symlink to the
so.3.1 version, then you can add the following to your library QPG [note: I
don’t recommend changing your application QPG] to make reference to both
versions of your lib (somewhere in your QPG:Values block):
QPG:Values
…
QPG:PackageFilter proc=“x86” component=“none”
QPM:PackageManifest
QPM:ContentDescription
QPM:ContainsLibrary
xmlmultiple=“true”>libDataServer_API.so.3.0</QPM:ContainsLibrary
/QPM:ContentDescription
/QPM:PackageManifest
/QPG:PackageFilter
QPG:PackageFilter proc=“x86” component=“slib”
QPM:PackageManifest
QPM:ContentDescription
QPM:ProvidesLibrary
xmlmultiple=“true”>libDataServer_API.so.3.0</QPM:ProvidesLibrary
/QPM:ContentDescription
/QPM:PackageManifest
/QPG:PackageFilter
/QPG:Values
Please note that though this will work for you, it’s really not the correct
way to do it. The right way would be to fix your library versioning, so that
the NEEDED references work properly. Perhaps others will have suggestions on
how you might make the required changes to your build environment.
Don’t understand what is the problem here.
This is a common situation where we use the second digit to specify
‘adds functionnality’ so, applications compiled with previous versions,
as much as the higher digit is the same, can run perfectly. BUT,
application compiled with 3.1 cannot run with 3.0, this is because the
second digit is absolutely needed.
Maybe there is something that I didn’t really understand in your warning
because it’s very often used in unix world, no?
So, this is the reason why I include, in the qpg file, a symlink from
3.0 to 3.1.
The problem, and it’s absolutely correct regarding on how packager
works, this symlink is not taken in account in the ContainsLibrary tag.
That’s said, unless you have a better idea now, we can talk about your proposition:
Does your ProvidesLibrary tag need the corresponding file or is it just a reference?
Jerry Chappell
“Alain Bonnefoy” <> alain.bonnefoy@icbt.com> > wrote in message
news:> 3E6DA712.7020700@icbt.com> …
Hi,
I encounter a problem about shared libraries dependencies.
One of my packages provide a libDataServer_API.so.3.1 and a link
libDataServer_API.so.3.0 to libDataServer_API.so.3.1. which is, I think
a very common situation.
Now, I want to install an old package which use the old DataServer
library.
So, I run into a dependency problem because the DataServer package
provide the 3.1 library and not the 3.0!
Is it possible to solve this problem in the DataServer qpg file?
Do I have to really provide both library versions?
Thanks,
Alain.
\