All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Squires <dan@engineeredarts.co.uk>
To: Mikko.Rapeli@bmw.de
Cc: yocto@lists.yoctoproject.org
Subject: Re: [yocto] host file contamination with recipes using cmake and find_package
Date: Fri, 27 May 2022 16:37:40 +0100	[thread overview]
Message-ID: <4ef989e9-e640-e6e7-59e7-e8a64c724b18@engineeredarts.co.uk> (raw)
In-Reply-To: <YpDtCghBbiV8fiZO@korppu>

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

We are indeed using


inherit cmake


The CMakeLists.txt adds a few bits to CMAKE_CXX_FLAGS but does not 
outright clobber it. I have noticed in other recipes some things like:


EXTRA_OECONF = " --with-openssl=${STAGING_DIR_HOST}${prefix} \
                "

And from the docs it seems like this maybe intended to help with this, 
but I am not entirely sure. Does that look right?  I don't currently 
have access to one of the systems where the build is failing but I'll 
try it out next week.

Many thanks


On 27/05/2022 16:23, Mikko.Rapeli@bmw.de wrote:
> 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
-- 

*Dan Squires*
Senior Roboticist

www.engineeredarts.co.uk <https://www.engineeredarts.co.uk/>

EA Phone Number+44 (0)1326 378129

RoboThespian FB <https://www.facebook.com/RobotThespian> RoboThespian 
Twitter <https://twitter.com/robothespian> EA YouTube 
<http://youtube.com/EngineeredArts>
Engineered Arts Logo <https://www.engineeredarts.co.uk/>
*

Engineered Arts Ltd *
E1-E3 Church View Business Park,
Bickland Water Road,
Falmouth Cornwall,
TR11 4FZ
United Kingdom

Subscribe to Mailing List <https://www.engineeredarts.co.uk/mailing-list/>

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

  reply	other threads:[~2022-05-27 15:38 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 ` [yocto] " Mikko.Rapeli
2022-05-27 15:37   ` Daniel Squires [this message]
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=4ef989e9-e640-e6e7-59e7-e8a64c724b18@engineeredarts.co.uk \
    --to=dan@engineeredarts.co.uk \
    --cc=Mikko.Rapeli@bmw.de \
    --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.