Hi Emily,

To find the solution to your issue in a rational and deterministic way
we need to start from the error message.

What I understand is that while build recipe "opc-ua-server-gfex" you
get an error message that says in short "ld: cannot find
-lboost_python-mt".

Therefore you need to determine which recipe (and which package in
that recipe) provides the "boost_python-mt" library.

One way to determine this is to run something like this:

    find /local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/*/*/*/packages-split
-name libboost_python\*

This should show you which recipe, and which package produced by that
recipe has the library you are looking for.

The names of the first-level directories inside "packages-split" are
packages names.

Based on things you have mentioned in your previous e-mail my guess
would be that adding an RDEPENDS = "boost-python" should help, but I
might be wrong.

I hope this will help you move in the right direction.

Kind regards, Laurent.


On Tue, Mar 17, 2020 at 6:07 PM Emily <easmith5555@...> wrote:
>
> Hi Quentin -
>
> That's what I tried originally! DEPENDS on boost and not boost-python gives me the following error when trying to build my original recipe:
>
> /local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/recipe-sysroot-native/usr/bin/aarch64-poky-linux/../../libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/7.3.0/ld:
> cannot find -lboost_python-mt
>
> So I tried a bunch of other this which also didn't seem to work.
>
> Thanks for the response!
> Emily
>
>
> On Tue, Mar 17, 2020 at 11:04 AM Quentin Schulz <quentin.schulz@...> wrote:
>>
>> Hi Emily,
>>
>> On Tue, Mar 17, 2020 at 10:44:10AM -0500, Emily wrote:
>> > Hi all -
>> >
>> > I'm trying to build an opca recipe (
>> > https://github.com/kratsg/meta-l1calo/blob/add/opcServer/recipes-core/opc-ua/opc-ua-server-gfex_git.bb)
>> > and it's giving me a build error like:
>> >
>> > |
>> > /local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/recipe-sysroot-native/usr/bin/aarch64-poky-linux/../../libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/7.3.0/ld:
>> > cannot find -lboost_python-mt
>> >
>> > Which seems to indicated I need to add boost-python to my list of DEPENDS.
>> > When I do that I get the error:
>> >
>> > ERROR: Nothing PROVIDES 'boost-python' (but
>> > /local/d6/easmith5/rocko_bitbake/meta-l1calo/recipes-core/opc-ua/
>> > opc-ua-server-gfex_git.bb DEPENDS on or otherwise requires it). Close
>> > matches:
>> >   boost RPROVIDES boost-python
>> >
>> > I've tried adding PACKAGECONFIG_pn-boost="python" to both my local.conf and
>> > to the image definition as I saw this online, but neither seems to work. It
>> > seems like boost-python is being built (I can see it in the list when I run
>> > oe-pkgdata-utils list-pkgs -p boost) but it doesn't seem to be available at
>> > build for this recipe.
>> >
>> > If I remove boost from my list of DEPENDS I get an error about that, so
>> > obviously boost itself is available at build for the original recipe. I've
>> > also tried adding boost-native to DEPENDS, also did not work.
>> >
>> > Is there something obvious I'm missing, or some trick to making
>> > boost-python available at build for this other recipe?
>> >
>>
>> Ok so two things.
>>
>> Yes, I'd say you need python in PACKAGECONFIG for boost. However, it
>> seems it's already part of the default value of PACKAGECONFIG, c.f.
>> http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-support/boost/boost.inc?h=master#n45
>> so if no bbappend is overriding it, I'd say you're safe. Better check
>> with the version in your layer that it's there.
>> If you don't want to check manually, try `bitbake -e boost | grep -e
>> "^PACKAGECONFIG="`
>>
>> DEPENDS contains only recipes (well, PROVIDES but PROVIDES has the name
>> of the recipe in it at all times) while RDEPENDS_* (usually ${PN}*) contains
>> only packages.
>>
>> So you need to DEPENDS on boost, not boost-python. That should be enough
>> hopefully!
>>
>> Quentin
>
>



--
Laurent Gauthier
Phone: +33 630 483 429
http://soccasys.com

Hi Emily,

On Tue, Mar 17, 2020 at 10:44:10AM -0500, Emily wrote:
> Hi all -
>
> I'm trying to build an opca recipe (
> https://github.com/kratsg/meta-l1calo/blob/add/opcServer/recipes-core/opc-ua/opc-ua-server-gfex_git.bb)
> and it's giving me a build error like:
>
> |
> /local/d6/easmith5/rocko_bitbake/poky/build/tmp/work/aarch64-poky-linux/opc-ua-server-gfex/1.0+gitAUTOINC+921c563309-r0/recipe-sysroot-native/usr/bin/aarch64-poky-linux/../../libexec/aarch64-poky-linux/gcc/aarch64-poky-linux/7.3.0/ld:
> cannot find -lboost_python-mt
>
> Which seems to indicated I need to add boost-python to my list of DEPENDS.
> When I do that I get the error:
>
> ERROR: Nothing PROVIDES 'boost-python' (but
> /local/d6/easmith5/rocko_bitbake/meta-l1calo/recipes-core/opc-ua/
> opc-ua-server-gfex_git.bb DEPENDS on or otherwise requires it). Close
> matches:
>   boost RPROVIDES boost-python
>
> I've tried adding PACKAGECONFIG_pn-boost="python" to both my local.conf and
> to the image definition as I saw this online, but neither seems to work. It
> seems like boost-python is being built (I can see it in the list when I run
> oe-pkgdata-utils list-pkgs -p boost) but it doesn't seem to be available at
> build for this recipe.
>
> If I remove boost from my list of DEPENDS I get an error about that, so
> obviously boost itself is available at build for the original recipe. I've
> also tried adding boost-native to DEPENDS, also did not work.
>
> Is there something obvious I'm missing, or some trick to making
> boost-python available at build for this other recipe?
>

Ok so two things.

Yes, I'd say you need python in PACKAGECONFIG for boost. However, it
seems it's already part of the default value of PACKAGECONFIG, c.f.
http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-support/boost/boost.inc?h=master#n45
so if no bbappend is overriding it, I'd say you're safe. Better check
with the version in your layer that it's there.
If you don't want to check manually, try `bitbake -e boost | grep -e
"^PACKAGECONFIG="`

DEPENDS contains only recipes (well, PROVIDES but PROVIDES has the name
of the recipe in it at all times) while RDEPENDS_* (usually ${PN}*) contains
only packages.

So you need to DEPENDS on boost, not boost-python. That should be enough
hopefully!

Quentin

Hi Alexander,

thanks for your message. I will try to explain my issue once again,
since it still seems not clearly formulated. We build our images on CI
(Jenkins). There, we have a shared download dir, so that we do not have
to fetch all sources on every build. This gets shared for our
"experimental" builds, that use latest git master HEAD (yes, evil
AUTOREV) and our "stable" builds, where only tagged (i.e. no AUTOREV
versions) are used. Our software uses the git tag to create a version.
So, when on experimental, you might get something like:

# ourCoolSoftware --version
This is ourCoolSoftware version 1.2.3-3 (gabcdef1)

What happens is, that people check their changes on the experimental
build. After testing, it is considered for the next release, so they
attach a version tag to the git repository and update the _<version>.bb
accordingly. Now they build the image with the "stable" profile. But the
hash "abcdef1" has not changed. Hence, although we pushed a new tag,
yocto git fetcher does not update the cached download git, since git
hashes match (same with SRCREV). Which means, even tough we have a
recipe ourcoolsoftware_1.2.4.bb with SRCREV="abcdef1..." which will
build the correct hash, our software checks the local repository, which
is missing the last tag and will still be reporting a wrong version
1.2.3-3 for example.

If we were to do a
bitbake -c cleanall ourcoolsoftware && bitbake ourcoolimage

then we get
# ourCoolSoftware --version
This is ourCoolSoftware version 1.2.4 (gabcdef1)

because we artificially force a complete fetch of the repository.

We usually do a clean build (no sstate / tmp / etc.) but we use the
download dir, because we do not see why we would need to download gcc
etc. every time. A workaround would be to bitbake -c cleanall our
packages, but it seems hacky and prone to error (need to keep lists of
our used software in at least two places). My question is therefore, if
this is a "bug" and if we were to investigate this and propose a patch,
if this could this be considered for merge, or if this behaviour is
intentional and adding a fetch --tags would be considered harmful in any
way.

Hope, I could bring my point across now.

Thanks and Regards,

  Matthias

On 3/16/20 9:43 AM, Alexander Kanavin wrote:
> 'devtool upgrade' updates SRCREV to match the version tag that you specify:
>
> devtool upgrade -V <tag>
>
> If you omit -V, it will upgrade to the latest tag. It updates PV as
> well. Why is it unsuitable for you?
>
> Alex
>
> On Mon, 16 Mar 2020 at 09:35, Matthias Schöpfer
> <matthias.schoepfer@...
> <mailto:matthias.schoepfer@...>> wrote:
>
>     Hi Alexander,
>
>     does it solve the Problem of a SRCREV, that has been fetched (for
>     example for a _git testbuild) and now gets a tag applied and build with
>     the _<version> build. The problem is *not* that the yocto PV package is
>     wrong *nor* that the wrong version of the software gets build! The
>     problem is, that the tag does not get fetched and our software gets its
>     version from the git tags. Since this is very convenient to have the
>     version information in one place only, we will not change this.
>
>     Thanks and Regards,
>
>         Matthias
>
>     On 3/15/20 5:02 PM, Alexander Kanavin wrote:
>      > On Sun, 15 Mar 2020 at 15:04, Matthias Schoepfer via
>      > Lists.Yoctoproject.Org <http://Lists.Yoctoproject.Org>
>     <http://Lists.Yoctoproject.Org>
>      > <matthias.schoepfer=googlemail.com@...
>     <mailto:googlemail.com@...>
>      > <mailto:googlemail.com@...
>     <mailto:googlemail.com@...>>> wrote:
>      >
>      >     2) It allows for very convenient bump of versions. We develop a
>      >     product,
>      >     so, version bumps are on daily or weekly basis. All that is
>     needed
>      >     is to
>      >     rename the .bb file. No need to edit SRCREV.
>      >
>      >
>      > You can trivially script SRCREV updates ('devtool upgrade'/'devtool
>      > finish'). The disadvantage of using tags is that you lose
>      > reproducibility, as tags can be moved or deleted, and so I wouldn't
>      > encourage this practice.
>      >
>      > Alex
>
>
>     --
>
>     Dr.-Ing. Matthias Schoepfer
>     Mobile: +49 175 2062739
>     email: matthias.schoepfer@...
>     <mailto:matthias.schoepfer@...>
>


--

Dr.-Ing. Matthias Schoepfer
Mobile: +49 175 2062739
email: matthias.schoepfer@...