On 02/14/2010 08:23 PM, David Haller wrote:
Hello,
On Sun, 14 Feb 2010, Michael Matz wrote: [..]
Hence, you need to determine this before. If they turn out to be plugins, you simply need to package them into a non-libdir directory private to COLLADA (and need to make the changes in there to make it find those plugins in that directory).
I agree. Iff they're libraries though, and the 'lib-' prefix suggests that[1], I'd suggest static linking. If they're plugins, they should be included in the main or a -plugin package, and for an SONAME it seems to be common to use just 'foo.so' for the plugin foo.so. To use 'lib-' prefixes or versioned sonames for plugins is a bit uncommon.
In that case you also don't need to add version suffixes. A SONAME still would be good to have but isn't that terribly necessary either anymore.
Aye. For Dave: you can set the SONAME to "libfoo.so.N" by passing
-soname libfoo.so.N
to the linker ('ld') which you can do via gcc by using
-Wl,-soname,libfoo.so.N
Thanks, I will try that option, I'm still fighting with the SConscript option passing, I have a patch for that. I also need to get scons to accept options passed from the spec file, I think it's "import os" but I've yet to test it.
or the equivalent
-Wl,-soname -Wl,libfoo.so.N
(or '-Wl,-soname,foo.so' for a plugin)
Collada is definitely not a plugin, blender had a collada plugin a few years ago, it's an integrated part of the blender sources that needs to build against the openCOLLADA libraries.
on the commandline creating the .so (i.e. the 'gcc .. -shared ..' call). Depending on the buildsystem, it can be quite a pain to 'insert' that. *sigh*
BTW: the SONAME is what rpm will also pick up as a dependency and provide (per default), possibly garnished with arch-stuff.
Rpm picks up the sonames I created with:- "find *.so -exec mv -v {} {}.0.0.0 \; -exec ln -s {}.0.0.0 {} \; -exec ln -s {}.0.0.0 {}.0 \;" and puts the correct dependencies in blender but I wasn't aware of the SONAME lable in the binary which I imagine is for ldconfig or not?
HTH, -dnh
[1] OTOH, I see no reason why plugins shouldn't have versions and a lib-prefix. It's just not commonly used / a convention, but I don't actually see where it'd do harm (other than suggest it's a generally useable lib). I think, much of it depends on the naming scheme. And actually, xmms uses lib- prefixes for it's plugins (e.g. ${prefix}/lib/xmms/Output/libdisk_writer.so). If plugins were named like lib${APP}[-_]?plugin[-_]${FUNCTION}.so[.${VERSION}], I don't think there'd be confusions about lib/plugin, e.g.: ${prefix}/lib/xmms/Output/libxmmsplugin_disk_writer.so.0 would be as easily identifiable as a plugin as the current plugin. Or as another example consider: ${prefix}/lib/mplayer/vidix/nvidia_vid.so vs. ${prefix}/lib/mplayer/vidix/libmplayerplugin_vidix_nvidia_vid.so.0 or ${prefix}/lib/mplayer/vidix/libmplayerplugin_vidix_nvidia.so.0 or whatever.
Blender has a number of plugins that reside under %_libdir/%name/ and they neither have a version number nor a lib prefix, this was already there when I took over as maintainer and from what I read in Shared_Library_Packaging_Policy is acceptable. Thanks Dave P -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org