Bug 7136

This is due to the fact that these prebuilt libraries you have don't follow the standard naming practices for Linux shared libraries. For example on my Ubuntu system:

lrwxrwxrwx 1 root root     35 May 13  2013 /usr/lib/x86_64-linux-gnu/libz.so -> /lib/x86_64-linux-gnu/libz.so.1.2.8
lrwxrwxrwx 1 root root     13 May 13  2013 /lib/x86_64-linux-gnu/libz.so.1 -> libz.so.1.2.8
-rw-r--r-- 1 root root 100728 May 13  2013 /lib/x86_64-linux-gnu/libz.so.1.2.8

So there is a .so file symlinked to a .so.<majorversion> which in turn links to a .so.<minorversion>.<pointversion>

Our default patterns for library packaging match this format, not the one your closed source shared libs are using. This isn't really something we'd want to change the defaults for.

Note that your lib would have been packaged, its just the .so file would have been placed into libfoo-dev_0.1_arch.ipk since the system would (incorrectly) think it was a development file.

Richard - thanks for taking the time to look a this.

I tried installing as per standard shared library naming practices, but .so file is still omitted from ipk. Snippet from intuvision_6.3.1.bb below installs libintuVision.so.6.3.1 and libintuVision.so.6 but not libintuVision.so

libiv = "libintuVision.so"
do_install () {
   PV_MAJOR=`echo ${PV} | cut -d '.' -f 1`
   install -m 0755 -d ${D}${libdir}
   install -m 0644 ${WORKDIR}/${MACHINE_ARCH}/${libiv}.${PV} ${D}${libdir}
   ln -sf ${D}${libdir}/${libiv}.${PV} ${D}${libdir}/${libiv}.${PV_MAJOR}
   ln -sf ${D}${libdir}/${libiv}.${PV} ${D}${libdir}/${libiv}  
}

Feedback on do_install is welcome!

(In reply to comment #2)
> Richard - thanks for taking the time to look a this.
> 
> I tried installing as per standard shared library naming practices, but .so
> file is still omitted from ipk. Snippet from intuvision_6.3.1.bb below
> installs libintuVision.so.6.3.1 and libintuVision.so.6 but not
> libintuVision.so
> 
> libiv = "libintuVision.so"
> do_install () {
>    PV_MAJOR=`echo ${PV} | cut -d '.' -f 1`
>    install -m 0755 -d ${D}${libdir}
>    install -m 0644 ${WORKDIR}/${MACHINE_ARCH}/${libiv}.${PV} ${D}${libdir}
>    ln -sf ${D}${libdir}/${libiv}.${PV} ${D}${libdir}/${libiv}.${PV_MAJOR}
>    ln -sf ${D}${libdir}/${libiv}.${PV} ${D}${libdir}/${libiv}  
> }
> 
> Feedback on do_install is welcome!

When you did this, did you remember to remove the FILES and PACKAGES changes you'd made? This should work...

I'd also add that there are the oe_soinstall and oe_libinstall functions (see meta/classes/utils.bbclass) which can handle some of this for you.

If the binary comes as a .so I wouldn't bother making symlinks as they'll never be used.  The solution here is to just set FILES_${PN} = "${libdir]/*.so"

Some form of additional sanity test to identify this happening would be useful as many people don't know how library versioning is meant to work - I find myself answering this for someone in bugzilla/irc/mailing list once every few weeks.  Something along the lines of "if PN is empty and PN-dev contains a .so that isn't a symlink, warn".

Ross: I agree with your comments. They would certainly improve ease of use with pre-built binaries. I set FILES_${PN} = "${libdir}/*.so" , but no change in behavior. .so is still not packaged.

Richard: My 'intuvision' example used default FILES and PACKAGES values but .so is still not packaged. Thanks for heads up on oe_soinstall. This caused a 'too much recursion' python exception at split_and_strip_files line 222. Further investigation showed that vendor's so did not have an ELF 'soname' tag and oe_soinstall does not test for its absence. Maybe this is the root cause. I'll get vendor to add the tag and report back.

Sorry, you'll need to unset FILES_${PN}-dev, which will be taking the files before ${PN} can.

Ross: I also need to package include files so my app can use this library. Unsetting FILES_${PN}-dev causes an "installed but not shipped" error.

So you'll need something like this:

FILES_${PN} = "${libdir}/*.so"
FILES_${PN}-dev = "${includedir}/*.h"

Fix the paths as appropriate.

I received .so from vendor with SONAME tag and oe_soinstall now works as expected, creating valid package.

do_install () {
   install -m 0755 -d ${D}${libdir}
   oe_soinstall ${WORKDIR}/${MACHINE_ARCH}/libintuVision.so.${PV} ${D}${libdir}
   oe_soinstall ${WORKDIR}/${MACHINE_ARCH}/libDigitalVideo.so.${PV} ${D}${libdir}
   install -m 0755 -d ${D}${includedir}
   install -m 0755 ${WORKDIR}/include/* ${D}${includedir}
}

Ross: If I had time to fiddle about with recipe I may have been able to generate a package with .so that didn't have SONAME tag, but I didn't think it was worth the effort.

Going forward I recommend three steps
1. Document process of adding prebuilt libraries. Is there a place I can do this so that Scott can edit content and transfer to public docs?
2. Open a new issue for oe_soinstall throwing an exception if .so doesn't have SONAME tag
3. Don't silently fail to package a library if that is obviously the intent of the recipe. Not so sure how to fix this.

I'll do (1) and (2). Maybe this bug stays open to flag (3). I'll attempt to fix (2) and send a patch to mailing list.

Henry, did filing new bugs for (1) and (2) happen?

I'm not sure what could be done about (3), maybe sanity-checking that libfoo.so in the -dev package is a symlink?  I wonder if that would have too many false-positives.

For future reference I think the neatest way to package a non-versioned library would be to:

# This says that the real library is .so
SOLIBS=".so"
# This clears the dev library names so they don't get packaged into PN-dev
FILES_SOLIBSDEV=""

Sorry, I dropped the ball on this.

(1). Thanks to Ross for addressing this in https://wiki.yoctoproject.org/wiki/TipsAndTricks/PackagingNonversionedLibrary
(2) I created bug 10146.
(3) I'll go with Ross's recommendation and drop the request as this doesn't seem to be an issue for anyone else.

(2) is now integrated so this bug is now about getting (1) into the actual documentation.

Scott, can you massage the documentation I wrote at https://wiki.yoctoproject.org/wiki/TipsAndTricks/PackagingNonversionedLibrary into the manual?  Under the development manual seems sensible, maybe a subsection under Writing A New Recipe?

Assigning to Mark.

Mark, see comment #15.  I wrote a wiki page with an overview for packaging non-versioned libraries which needs to be integrated somewhere into the proper documentation.

Now closed in "master"
https://git.yoctoproject.org/yocto-docs/commit/?id=5e46cad9e4b4ab03e33f4d5aea34e56f6b15fe27

Available on https://docs.yoctoproject.org/dev-manual/common-tasks.html#working-with-pre-built-libraries