[yocto] Trying to build a non-autotools package that contains only a lib. Getting empty archive - package is not generated

[Brian Hutchinson]

On Thu, Dec 5, 2013 at 11:11 AM, Chris Larson <clarson at kergoth.com> wrote:

>
> On Thu, Dec 5, 2013 at 6:42 AM, Brian Hutchinson <b.hutchman at gmail.com>wrote:
>
>> On Wed, Dec 4, 2013 at 5:38 PM, Chris Larson <clarson at kergoth.com> wrote:
>>
>>>
>>> On Wed, Dec 4, 2013 at 3:29 PM, Brian Hutchinson <b.hutchman at gmail.com>wrote:
>>>
>>>> On Wed, Dec 4, 2013 at 5:10 PM, Chris Larson <clarson at kergoth.com>wrote:
>>>>
>>>>>
>>>>> do_install is the task that installs. If your makefile has an install
>>>>> target, you’d define a do_install that runs it. But not all makefiles
>>>>> provide an equivalent to automake’s DESTDIR, which is why we don’t provide
>>>>> a do_install for non-autotools make-based buildsystems. Either manually
>>>>> install the library where it belongs in your do_install, e.g. with the
>>>>> ‘install’ or ‘cp’ commands, or define one which runs the appropriate make
>>>>> command to install the files into ${D}.
>>>>>  --
>>>>>
>>>>> Thanks Chris.
>>>>
>>>> I do have a do_install that is copying stuff to ${D}/usr/lib which puts
>>>> things in my sysroot ... but what target do I use to get stuff into the
>>>> package which is used by my IMAGE_INSTALL line?  When I tar tvf my
>>>> core-image.tar and grep for my .so it currently isn't there ... but it and
>>>> the headers are in the sysroot.
>>>>
>>>
>>> do_install. The contents of ${D} are where the FILES globs are matched.
>>> We don’t include the raw libfoo.so, since that’s supposed to be a symlink.
>>> If your lib is missing an SONAME, it’d be named incorrectly and be missing
>>> a symlink, and the lib would end up in the -dev package instead of the main
>>> package.
>>> --
>>>
>>> The lib that the makefile generates is just a soname  like libfoo.so.
>> So you're telling me it will not pick that file up?  I guess I need to find
>> the class that handles this and study it as I'm probably not picking up all
>> you're telling me.  Like I said, this used to work and now it doesn't so
>> I'm still at a loss as to what I need to do.  It is making it into the
>> sysroot but not the package and the rootfs image is built from all the
>> IMAGE_INSTALL package names so it isn't making it into the rootfs.
>>
>> Do I just cheat and make my do_install copy my .so file to
>> packages-split/mypackage/usr/lib?
>>
>
> The best fix would be to properly name and version your library, e.g.
> libfoo.so.2.4, with libfoo.so.2 and libfoo.so symlinks, which is the most
> common practice, but if that’s not an option, or will take too much time,
> yes, you can absolutely make your .so end up in the main package.
>
> As i said earlier, it’s the *packaging* process that puts the .so in the
> -dev package, as common practice is that the .so is a symlink only used in
> development. If your do_install already installs the .so to ${D}${libdir},
> you just need to alter the globs used in the FILES variables to change
> which package it ends up in. To add your non-symlink .so to the main
> package rather than the ${PN}-dev package:
>
>     # Add the .so to the main package’s files list
>     FILES_${PN} += “${libdir}/*.so”
>     # Make sure it isn’t in the dev package’s files list
>     FILES_SOLIBSDEV = “"
>
> Should do it, as far as I can tell.
>
>
I had FILES_${PN} += “${libdir}/*.so” in there and that didn't work.  Maybe
it was because I was missing the FILES_SOLIBSDEV = “" you mentioned.  I'll
play with it some more and see what happens.  I first started out with
FILES_${PN} += “${libdir}/*.so” and when that didn't work I tried other
things in the FILES_${PN} = line to try and get it picked up.  When I
couldn't get any of it to work and then saw others (well, at least the link
I provided) were seeing the same thing I figured it was time to quit
spinning my wheels and consult the big guns :)

Regards,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20131205/4d2d562c/attachment.html>