* 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.