From: <Mikko.Rapeli@bmw.de>
To: <dan@engineeredarts.co.uk>
Cc: <yocto@lists.yoctoproject.org>
Subject: Re: [yocto] host file contamination with recipes using cmake and find_package
Date: Fri, 27 May 2022 15:23:54 +0000 [thread overview]
Message-ID: <YpDtCghBbiV8fiZO@korppu> (raw)
In-Reply-To: <VDCD.1653664077949368330.uKFK@lists.yoctoproject.org>
Hi,
On Fri, May 27, 2022 at 08:07:57AM -0700, Daniel Squires wrote:
> Hi,
> We have an internal source tree, I'll call it libA for brevity here, which uses cmake and find_package to build against openssl as follows:
>
> find_package(OpenSSL REQUIRED)
>
> The recipe for this source runs fine but some subsequent ones that depend on it (libB, libC etc) fail on some systems saying that a library file (libcrypto.so.1.1) required by libA cannot be found. Now it seems that the build for libA is managing to find and link against libcrypto.so.1.1 from the host libraries found under /usr. I have seen issues like this many years ago but not experienced any such issues since then until recently.
>
> Do we need to do something special in the recipe to prevent this happening? At first I thought I was going to find some hardcoded absolute paths in the CMakeLists.txt file of libA as I have in the past but there is nothing like that.
Usually the problem is that the application CMakeLists.txt or other custom CMake
snippet code is not obeying the bitbake generated toolchain.cmake file and the
variables set there. I presume your application recipe is doing "inherit cmake".
The application side can for example overwrite the various variables which set
the cross compiler sysroot.
Cheers,
-Mikko
next prev parent reply other threads:[~2022-05-27 15:24 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-27 15:07 host file contamination with recipes using cmake and find_package Daniel Squires
2022-05-27 15:23 ` Mikko.Rapeli [this message]
2022-05-27 15:37 ` [yocto] " Daniel Squires
2022-05-27 15:44 ` Mikko.Rapeli
2022-05-31 15:15 ` Daniel Squires
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YpDtCghBbiV8fiZO@korppu \
--to=mikko.rapeli@bmw.de \
--cc=dan@engineeredarts.co.uk \
--cc=yocto@lists.yoctoproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.