All of lore.kernel.org
 help / color / mirror / Atom feed
* Packaging an externally built library?
@ 2015-10-23 22:05 Smith, Daniel W
  2015-10-23 22:18 ` Burton, Ross
  2015-10-23 22:22 ` Jeremy A. Puhlman
  0 siblings, 2 replies; 3+ messages in thread
From: Smith, Daniel W @ 2015-10-23 22:05 UTC (permalink / raw)
  To: yocto@yoctoproject.org

[-- Attachment #1: Type: text/plain, Size: 1827 bytes --]

I have an externally built library (libcdpfsw.so) that I am trying to install in my image.  The library is written in Ada, so it is built using an external Ada compiler.  I've tested it on the target and it works, but I'd like it to be installed in my image.

I verified that the do_install works correctly by inspecting the logs and the image folder for the directory.

I'm having problems getting past the packaging and QA checks to build my rootfs.

I was originally having a problem with NO GNU HASH in the package QA check so I added these to my recipe.
#
# Set these flags to bypass Yocto build system
# QA checking because this package is built outside of Yocto.
#
INHIBIT_PACKAGE_STRIP = "1"
INHIBIT_PACKAGE_DEBUG_SPLIT = "1"
INSANE_SKIP_${PN} = "ldflags"
INSANE_SKIP_${PN}-dev = "ldflags"

FILES_${PN} += " ${libdir}/*.so"

If I look through the packaging logs it looks like it attampts to create a bunch of different packages (cdp-fsw, cdp-fsw-dbg, cdp-fsw-dev, cdp-fsw-doc, cdp-fsw-locale) but most of them end up being empty except cdp-fsw-dev.  Then if I look through the RPMs there is no cdp-fsw there is only a cdp-fsw-dev and cdp-fsw-dbg.

Then when do_rootfs is executed it fails because it can't find a package provider for cdp-fsw.

Why is it automatically creating a <xxxx>-dev package? Can I override this?

-Daniel Smith



This message and any enclosures are intended only for the addressee.  Please 
notify the sender by email if you are not the intended recipient.  If you are 
not the intended recipient, you may not use, copy, disclose, or distribute this 
message or its contents or enclosures to any other person and any such actions 
may be unlawful.  Ball reserves the right to monitor and review all messages 
and enclosures sent to or from this email address.

[-- Attachment #2: Type: text/html, Size: 4514 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Packaging an externally built library?
  2015-10-23 22:05 Packaging an externally built library? Smith, Daniel W
@ 2015-10-23 22:18 ` Burton, Ross
  2015-10-23 22:22 ` Jeremy A. Puhlman
  1 sibling, 0 replies; 3+ messages in thread
From: Burton, Ross @ 2015-10-23 22:18 UTC (permalink / raw)
  To: Smith, Daniel W; +Cc: yocto@yoctoproject.org

[-- Attachment #1: Type: text/plain, Size: 883 bytes --]

On 23 October 2015 at 23:05, Smith, Daniel W <dwsmith@ball.com> wrote:

> If I look through the packaging logs it looks like it attampts to create a
> bunch of different packages (cdp-fsw, cdp-fsw-dbg, cdp-fsw-dev,
> cdp-fsw-doc, cdp-fsw-locale) but most of them end up being empty except
> cdp-fsw-dev.  Then if I look through the RPMs there is no cdp-fsw there is
> only a cdp-fsw-dev and cdp-fsw-dbg.
>
>
The problem is that the default packaging assumes that any libraries are
versioned, shared libraries (as 99% of libraries are), so libfoo.so.* goes
into PN and libfoo.so (the development-time symlink) goes into PN-dev.

However your library isn't versioned, so these defaults don't apply.  At
least you'll want to override FILES_${PN} and FILES_${PN}-dev so that
FILES_PN contains ${libdir}/lib*.so, and set FILES_PN-dev to just install
the headers.

Ross

[-- Attachment #2: Type: text/html, Size: 1351 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Packaging an externally built library?
  2015-10-23 22:05 Packaging an externally built library? Smith, Daniel W
  2015-10-23 22:18 ` Burton, Ross
@ 2015-10-23 22:22 ` Jeremy A. Puhlman
  1 sibling, 0 replies; 3+ messages in thread
From: Jeremy A. Puhlman @ 2015-10-23 22:22 UTC (permalink / raw)
  To: yocto

[-- Attachment #1: Type: text/plain, Size: 2139 bytes --]

> FILES_${PN} += " ${libdir}/*.so"
>
> If I look through the packaging logs it looks like it attampts to 
> create a bunch of different packages (cdp-fsw, cdp-fsw-dbg, 
> cdp-fsw-dev, cdp-fsw-doc, cdp-fsw-locale) but most of them end up 
> being empty except cdp-fsw-dev.  Then if I look through the RPMs there 
> is no cdp-fsw there is only a cdp-fsw-dev and cdp-fsw-dbg.
>
> Then when do_rootfs is executed it fails because it can’t find a 
> package provider for cdp-fsw.
>
> Why is it automatically creating a <xxxx>-dev package? Can I override 
> this?
>

Because the package list has PN at the end by default:
PACKAGES="${@bb.utils.contains('PTEST_ENABLED', '1', '${PN}-ptest', '', 
d)} ${PN}-dbg ${PN}-staticdev ${PN}-dev ${PN}-doc ${PN}-locale 
${PACKAGE_BEFORE_PN} ${PN}"
and
${PN}-dev lists ${libdir}/*.so
"${includedir} ${FILES_SOLIBSDEV} ${libdir}/*.la ${libdir}/*.o 
${libdir}/pkgconfig ${datadir}/pkgconfig ${datadir}/aclocal 
${base_libdir}/*.o ${libdir}/${BPN}/*.la ${base_libdir}/*.la"
As part of its files list.

When the packages-split directory is created, it processes the packages 
list in order extracting the files for each package. When ${PN} is 
processes "*.so" files have already been pulled
in to the ${PN}-dev package.

Normally in linux *.so files are symlinks to the actual versioned 
libraries only used for linking. You can fix the binary libraries to 
conform more correctly. If the library is using soname you will likely 
need to do this
anyways to run applications linked against it. To get the soname you 
would do:
<cross prefix>-objdump -x libz.so.1  | grep SONAME
if it gives you something like:
SONAME               libz.so.1

You would need to install the library with the name returned from 
objdump, then create a .so symlink to that library. The versioned 
library would get picked up in ${PN}.

If it is not using soname and the linked applications are really only 
looking for lib<libname>.so, then you can redefine PACKAGES to include 
just ${PN} or a subset of the normally defined
packages.

-- 
Jeremy A. Puhlman
jpuhlman@mvista.com

[-- Attachment #2: Type: text/html, Size: 3520 bytes --]

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2015-10-23 22:23 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-10-23 22:05 Packaging an externally built library? Smith, Daniel W
2015-10-23 22:18 ` Burton, Ross
2015-10-23 22:22 ` Jeremy A. Puhlman

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.