[opensuse-packaging] Library naming dilemma
Hi, I'm packaging openCOLLADA which consists of libraries needed by the soon to be released blender-2.5x. ATM I have the libs in a separate sub package for each and a devel package. I see that I'm allowed to package all the libraries in one rpm, which one is preferable? My other question is - although I've packaged libOpenCOLLADAFramework.so.0.0.775 in sub package libOpenCOLLADAFramework0 I still get an rpmlint warning - libOpenCOLLADAFramework0.x86_64: W: shlib-policy-missing-lib and libOpenCOLLADAFramework0.x86_64: W: no-soname /usr/lib64/libOpenCOLLADAFramework.so.0.0.775. What am I doing wrong? I get these warnings for each lib. Package is at home:plater:blender openCOLLADA Thanks Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 10/23/2010 04:06 PM, Dave Plater wrote:
Hi, I'm packaging openCOLLADA which consists of libraries needed by the soon to be released blender-2.5x. ATM I have the libs in a separate sub package for each and a devel package. I see that I'm allowed to package all the libraries in one rpm, which one is preferable? My other question is - although I've packaged libOpenCOLLADAFramework.so.0.0.775 in sub package libOpenCOLLADAFramework0 I still get an rpmlint warning - libOpenCOLLADAFramework0.x86_64: W: shlib-policy-missing-lib and libOpenCOLLADAFramework0.x86_64: W: no-soname /usr/lib64/libOpenCOLLADAFramework.so.0.0.775. What am I doing wrong? I get these warnings for each lib. Package is at home:plater:blender openCOLLADA Thanks Dave P
Correct me if I'm wrong, the openCOLLADA package doesn't have a mechanism for adding soname to the lib during build time so I have to do that as well. Thanks Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Sat, 23 Oct 2010 18:24:30 +0200, Dave Plater <davejplater@gmail.com> wrote:
Correct me if I'm wrong, the openCOLLADA package doesn't have a mechanism for adding soname to the lib during build time so I have to do that as well.
What's the project for it? Then I might have a look at it and see where I can help you. Philipp -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 10/24/2010 01:29 AM, Philipp Thomas wrote:
On Sat, 23 Oct 2010 18:24:30 +0200, Dave Plater <davejplater@gmail.com> wrote:
Correct me if I'm wrong, the openCOLLADA package doesn't have a mechanism for adding soname to the lib during build time so I have to do that as well.
What's the project for it? Then I might have a look at it and see where I can help you.
Philipp
Sorry, home:plater openCOLLADA . ATM I'm trying to find how to pass "--soname=" to ld. Thanks Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 10/24/2010 01:29 AM, Philipp Thomas wrote:
On Sat, 23 Oct 2010 18:24:30 +0200, Dave Plater <davejplater@gmail.com> wrote:
Correct me if I'm wrong, the openCOLLADA package doesn't have a mechanism for adding soname to the lib during build time so I have to do that as well.
What's the project for it? Then I might have a look at it and see where I can help you.
Philipp
I've added , LINKFLAGS = '-Wl,--soname=libxxxx.so.0', to the libraries's SConscript files so far but I need to get a proper versioning system in place. Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Sun, 24 Oct 2010, Dave Plater wrote:
On 10/24/2010 01:29 AM, Philipp Thomas wrote:
On Sat, 23 Oct 2010 18:24:30 +0200, Dave Plater <davejplater@gmail.com> wrote:
Correct me if I'm wrong, the openCOLLADA package doesn't have a mechanism for adding soname to the lib during build time so I have to do that as well.
What's the project for it? Then I might have a look at it and see where I can help you.
Philipp
I've added , LINKFLAGS = '-Wl,--soname=libxxxx.so.0', to the libraries's SConscript files so far but I need to get a proper versioning system in place. Dave P
You should talk with upstream about this to get consistency across distributions. Richard. -- Richard Guenther <rguenther@suse.de> Novell / SUSE Labs SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746 - GF: Markus Rex -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 10/29/2010 04:44 PM, Richard Guenther wrote:
On Sun, 24 Oct 2010, Dave Plater wrote:
On 10/24/2010 01:29 AM, Philipp Thomas wrote:
On Sat, 23 Oct 2010 18:24:30 +0200, Dave Plater <davejplater@gmail.com> wrote:
Correct me if I'm wrong, the openCOLLADA package doesn't have a mechanism for adding soname to the lib during build time so I have to do that as well.
What's the project for it? Then I might have a look at it and see where I can help you.
Philipp
I've added , LINKFLAGS = '-Wl,--soname=libxxxx.so.0', to the libraries's SConscript files so far but I need to get a proper versioning system in place. Dave P
You should talk with upstream about this to get consistency across distributions.
Richard.
I've already given them a patch to enable the libdir to be passed to scons and allow static library builds to use shared system libs which they've incorporated in svn. When I have a moment I'll pass them some more. They only build openCOLLADA for windows and mac. I'm not sure what the blender devs use, I think they build against pre built static libs. Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Fri, 29 Oct 2010 19:43:25 +0200, Dave Plater <davejplater@gmail.com> wrote:
I've already given them a patch to enable the libdir to be passed to scons and allow static library builds to use shared system libs which they've incorporated in svn.
I think you should be talking to upstream scons developers and ask them if there is a way to incorporate library versions. scons already has rules to determine what tool(s) and options to use for creating shared libraries and what prefix and suffix to use based on the host OS. It should be relatively easy to add library versions. But that needs people with knowledge of Scons and Python. In the end you should be able to state major, minor and patch version and have scons turn that into soname: <lib_prefix><lib_name><lib_suffix>.<lib_major> lib_filename: <lib_prefix><lib_name><lib_suffix>.<lib_major>.<lib_minor>.<lib_patch> a symlink from <lib_prefix><lib_name><lib_suffix> to the above plus a symlink soname to lib_filename, though the latter will automatically created by ldconfig when it's run it (un)installl time. Philipp -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 10/30/2010 09:25 PM, Philipp Thomas wrote:
On Fri, 29 Oct 2010 19:43:25 +0200, Dave Plater <davejplater@gmail.com> wrote:
I've already given them a patch to enable the libdir to be passed to scons and allow static library builds to use shared system libs which they've incorporated in svn.
I think you should be talking to upstream scons developers and ask them if there is a way to incorporate library versions. scons already has rules to determine what tool(s) and options to use for creating shared libraries and what prefix and suffix to use based on the host OS. It should be relatively easy to add library versions. But that needs people with knowledge of Scons and Python.
In the end you should be able to state major, minor and patch version and have scons turn that into
soname: <lib_prefix><lib_name><lib_suffix>.<lib_major> lib_filename: <lib_prefix><lib_name><lib_suffix>.<lib_major>.<lib_minor>.<lib_patch>
a symlink from <lib_prefix><lib_name><lib_suffix> to the above plus a symlink soname to lib_filename, though the latter will automatically created by ldconfig when it's run it (un)installl time.
Does this mean that it isn't necessary to include the .so.0 link in the rpm? I've seen quite a few packages with it included.
Philipp
Ffado builds with scons and has library versioning, the developers have come quite far since early this year with scons builds. Their SConstruct and SConscripts layouts are quite different from openCOLLADA so unfortunately I couldn't use their ideas. I can't go messing up the collada windows and mac builds when I have their trust. They have a no release svn only policy so I can do what I like with the linux build part. The ffado scons build is an interesting one to look at it's in my home and multimedia:libs. One good thing has come from fighting with scons files is my python knowledge has gone from zero to novice without any studying. At least I;'m free to define a %libversion macro to version my libs in the spec file I would like to be sure that I'm doing it right though, I still don't quite understand the libtool versioning, current is obviously the major version number incremented when the api changes, the age.revision part is the confusing part but your use of major.minor.patch is clearer. Would the patch number indicate a change between releases?. Does cmake have a library versioning system? The openCOLLADA package contains a ruby script to generate CMakelists.txt'es and it seemed to work in my early days of trying to build openCOLLADA but I need to send it to factory before I try anything new, it doesn't seem like anything is going to change much in the future. Changing blender from scons to cmake took a while. I will attack the scons built in library versioning and soname matter when I've sorted out blender. The blender foundation has so many developers that it's difficult to get the right answers sometimes. I have a "no menus" problem which in the past was due to missing python scripts in the users home, I utilized a wrapper script but now the /.blender directory isn't built anymore, they've changed to %_datadir/%name/%version, and even with the scripts in every logical place I still have no menu. The main difference between my build and other blender people who have shared their cmake cache with me is, I don't use the embedded python3 I use the systems python3, if that's the problem then I'll have a valid bug, so I'm trying the embedded python3 at the moment. I had to install the windows version in vbox xp to see what it's supposed to look like. Unfortunately blenders ui generation is quite different to the norm which makes it difficult for me to use gdb. Regards Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Sun, 31 Oct 2010 03:51:38 +0200, Dave Plater <davejplater@gmail.com> wrote:
Does this mean that it isn't necessary to include the .so.0 link in the rpm?
It isn't strictly needed but it won't hurt to do so. To check just cd into a directory containing the library file and as root do 'ldconfig -n .' and you'll see it created the symlink.
I've seen quite a few packages with it included.
Yes, it seems that only very few people know that. Plus most packages use libtool for handling libraries and it doesn't special case linux when it comes to installation.
Their SConstruct and SConscripts layouts are quite different from openCOLLADA so unfortunately I couldn't use their ideas. I can't go messing up the collada windows and mac builds when I have their trust.
If done right, it shouldn't mess with windows or mac builds in any way as the needed changes are Linux specific. So given that it seems like scons does differentiate by OS the change should be doable. But it definitely will need solid scons and python knowledge.
I still don't quite understand the libtool versioning, current is obviously the major version number incremented when the api changes, the age.revision part is the confusing part
I found the description of the libtool versioning in libtool.info rather precise. From what you write I guess you did read info '(libtool.info.gz)Libtool' versioning which part don't you understand? I agree it is a more difficult to understand as it is a more powerful system then simply using the version number of the project. The latter doesn't show in any way that the libraries developers do watch ABI compatibility and change soname majors when they do incompatible ABI changes (like changing the number and/or types of function parameters or changing the size of structs).
but your use of major.minor.patch is clearer. Would the patch number indicate a change between releases?
It's a matter of definition. It seems most developers do think about project/package versioning but do not think about library versioning or ABI compatibility.
Does cmake have a library versioning system?
I have no idea as I've never really used anything other than classic make.
I will attack the scons built in library versioning and soname matter when I've sorted out blender.
Do try and to get some scons help somewhere. There should be mailing lists, usenet groups or web forums where you can get the suport you need for that task.
Unfortunately blenders ui generation is quite different to the norm which makes it difficult for me to use gdb.
Looks like you've decided to tackle a serious beast :) Well, as a german saying goes 'much enemy, much honour' ;-) I whish you luck. Philipp -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 11/01/2010 03:24 AM, Philipp Thomas wrote:
On Sun, 31 Oct 2010 03:51:38 +0200, Dave Plater <davejplater@gmail.com> wrote:
Does this mean that it isn't necessary to include the .so.0 link in the rpm?
It isn't strictly needed but it won't hurt to do so. To check just cd into a directory containing the library file and as root do 'ldconfig -n .' and you'll see it created the symlink.
Interesting, what would be the effect of running 'ldconfig -n .' in the spec file during %install do you think?
I've seen quite a few packages with it included.
Yes, it seems that only very few people know that. Plus most packages use libtool for handling libraries and it doesn't special case linux when it comes to installation.
Their SConstruct and SConscripts layouts are quite different from openCOLLADA so unfortunately I couldn't use their ideas. I can't go messing up the collada windows and mac builds when I have their trust.
If done right, it shouldn't mess with windows or mac builds in any way as the needed changes are Linux specific. So given that it seems like scons does differentiate by OS the change should be doable. But it definitely will need solid scons and python knowledge.
I still don't quite understand the libtool versioning, current is obviously the major version number incremented when the api changes, the age.revision part is the confusing part
I found the description of the libtool versioning in libtool.info rather precise. From what you write I guess you did read info '(libtool.info.gz)Libtool' versioning which part don't you understand? I agree it is a more difficult to understand as it is a more powerful system then simply using the version number of the project. The latter doesn't show in any way that the libraries developers do watch ABI compatibility and change soname majors when they do incompatible ABI changes (like changing the number and/or types of function parameters or changing the size of structs).
but your use of major.minor.patch is clearer. Would the patch number indicate a change between releases?
It's a matter of definition. It seems most developers do think about project/package versioning but do not think about library versioning or ABI compatibility.
Does cmake have a library versioning system?
I have no idea as I've never really used anything other than classic make.
I will attack the scons built in library versioning and soname matter when I've sorted out blender.
Do try and to get some scons help somewhere. There should be mailing lists, usenet groups or web forums where you can get the suport you need for that task.
Unfortunately blenders ui generation is quite different to the norm which makes it difficult for me to use gdb.
Looks like you've decided to tackle a serious beast :) Well, as a german saying goes 'much enemy, much honour' ;-) I whish you luck.
Philipp
Yes, blender was my "baptism of fire" into the world of maintaining packages, I took over maintaining it to prevent it being dropped, it is an outstanding package for creating animations. At least the blender people are starting to take note of the bug I filed on their tracker by reopening it. You've supplied lot's of food for thought. Thanks Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Mon, 01 Nov 2010 13:52:16 +0200, Dave Plater <davejplater@gmail.com> wrote:
Interesting, what would be the effect of running 'ldconfig -n .' in the spec file during %install do you think?
Read the ldconfig man page and you know :) '-n' tells ldconfig to not cache anything and to only process those directories passed to it on the command line. So the additional '.' tells it to only process the current directory.
You've supplied lot's of food for thought. Thanks
You're welcome! Philipp -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 10/24/2010 01:29 AM, Philipp Thomas wrote:
On Sat, 23 Oct 2010 18:24:30 +0200, Dave Plater <davejplater@gmail.com> wrote:
Correct me if I'm wrong, the openCOLLADA package doesn't have a mechanism for adding soname to the lib during build time so I have to do that as well.
What's the project for it? Then I might have a look at it and see where I can help you.
Philipp
I've got home:plater:blender openCOLLADA to what I think is a workable package. I would appreciate if you would look it over. Thanks Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
participants (3)
-
Dave Plater -
Philipp Thomas -
Richard Guenther