I whipped up a quick spec to package Zenoss' wmi client and noticed it creates a libasync_wmi_lib.so.0 and libasync_wmi_lib.so.0.0.1 that their python script would otherwise copy during its install routine (obviously I wrote a native rpm section for installation).
Anyone know the naming convention associated with so's when they get compiled, what is the .0.1 extra file used for, they are slightly different.
Thanks, jlc
Joseph L. Casale wrote:
I whipped up a quick spec to package Zenoss' wmi client and noticed it creates a libasync_wmi_lib.so.0 and libasync_wmi_lib.so.0.0.1 that their python script would otherwise copy during its install routine (obviously I wrote a native rpm section for installation).
Anyone know the naming convention associated with so's when they get compiled, what is the .0.1 extra file used for, they are slightly different.
Thanks, jlc
Are you sure that libasync_wmi_lib.so.0 is not a symlink form libasync_wmi_lib.so.0.0.1? libasync_wmi_lib.so.0 would be library reference, and libasync_wmi_lib.so.0.0.1 is actual library file with version number. New version would then have for example libasync_wmi_lib.so.0.0.2 and libasync_wmi_lib.so.0 symlink would be changed to point to that new file. That way you always know which version is in use but your apps are now confused.
Ljubomir
On 25/06/11 02:15, Joseph L. Casale wrote:
I whipped up a quick spec to package Zenoss' wmi client and noticed it creates a libasync_wmi_lib.so.0 and libasync_wmi_lib.so.0.0.1 that their python script would otherwise copy during its install routine (obviously I wrote a native rpm section for installation).
Anyone know the naming convention associated with so's when they get compiled, what is the .0.1 extra file used for, they are slightly different.
Thanks, jlc
Some reading for you:
http://www.ibm.com/developerworks/library/l-shobj/
As Ljubomir said, libasync_wmi_lib.so.0 will be a symlink to libasync_wmi_lib.so.0.0.1. You can use objdump to find the soname(s) for shared objects, e.g:
objdump -p /path/to/libasync_wmi_lib.so.0.0.1 | grep SONAME
or just run ldconfig against them and observe what symlinks are created.
On 25/06/11 10:04, Ned Slider wrote:
On 25/06/11 02:15, Joseph L. Casale wrote:
I whipped up a quick spec to package Zenoss' wmi client and noticed it creates a libasync_wmi_lib.so.0 and libasync_wmi_lib.so.0.0.1 that their python script would otherwise copy during its install routine (obviously I wrote a native rpm section for installation).
Anyone know the naming convention associated with so's when they get compiled, what is the .0.1 extra file used for, they are slightly different.
Thanks, jlc
Some reading for you:
http://www.ibm.com/developerworks/library/l-shobj/
As Ljubomir said, libasync_wmi_lib.so.0 will be a symlink to libasync_wmi_lib.so.0.0.1. You can use objdump to find the soname(s) for shared objects, e.g:
objdump -p /path/to/libasync_wmi_lib.so.0.0.1 | grep SONAME
or just run ldconfig against them and observe what symlinks are created.
I forgot to say, wrt packaging, you should create the symlink(s) in the buildroot so that they are packaged rather than just running ldconfig in %post. That way, the symlinks are owned by the rpm package and won't be left dangling when the package is uninstalled.
Thanks, that was informative.
As Ljubomir said, libasync_wmi_lib.so.0 will be a symlink to libasync_wmi_lib.so.0.0.1. You can use objdump to find the soname(s) for shared objects, e.g:
objdump -p /path/to/libasync_wmi_lib.so.0.0.1 | grep SONAME
or just run ldconfig against them and observe what symlinks are created.
They are actually not symlinked, they are different sizes but objdump does suggest the SONAME is libasync_wmi_lib.so.0 for both? The odd part is ldd ran against the two binaries produced from the package (samba portion) only need glibc and popt libraries. The actual python stub that kicks off the make and install portions manually copies the binaries into a logical place, yet copies the so's into a lib/python directory under some user chosen prefix beside a pysamba module package in that directory. Looking through its code, it attempts to locate these libraries so unless I plan on leveraging some python I presume I can package away without any of this.
I forgot to say, wrt packaging, you should create the symlink(s) in the buildroot so that they are packaged rather than just running ldconfig in %post. That way, the symlinks are owned by the rpm package and won't be left dangling when the package is uninstalled.
That's another good point I'll keep in mind!
All this has been informative, thanks a lot guys, jlc
-
Joseph L. Casale -
Ljubomir Ljubojevic -
Ned Slider