From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6806948680239677440 X-Received: by 2002:a2e:8e2f:: with SMTP id r15mr7637921ljk.54.1592813353588; Mon, 22 Jun 2020 01:09:13 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a05:651c:30c:: with SMTP id a12ls3040718ljp.9.gmail; Mon, 22 Jun 2020 01:09:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwmB6bNDnI8CjpaSre+HuDs3YlJZdDQQAcCYlXHSbA3GiPP9nyOj+m4cTovPr1o2AlvGdpI X-Received: by 2002:a2e:9cd5:: with SMTP id g21mr8577493ljj.9.1592813352834; Mon, 22 Jun 2020 01:09:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592813352; cv=none; d=google.com; s=arc-20160816; b=GWj3YrBeRT2L+QpEVOe3czDxkLd7avTz/xjTZHafPDSRmhtItDV4RsY8pov5sJOgCL gPz0VVNVCSAvWYmshflWIT08QU91KAyMvGFYj3AmiZ9B/m+fLrGJWwVwHO1080fExAn1 ZgicnzEXIG7rm0rVU/77oMA7/X9TDv/Ry0Gg9SEPIxpUsLrvygDwnHoQBaEDFurPEgDy KrjkvPdfp/aXrVv9YUAJ0ZKQfv50MG5aGFB3cB4/3PBWV0SzkQlBsGrt/WYx/fL89lu4 9Q2ACxzHP9Kjn+O/yVkR9/zhVyQ113mOT5xASZfquDorF/nRt31MbfXi9BWkz9Mg0FsG XnFA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:references:to:from:subject; bh=M6fTLtYS54xUzy3pSox3Os6NV5VPkl/ru3KiPLteg1I=; b=WRurtwIHLBj8SOs64qHdSz50UvbTmxDAOV4iQ6zvCIud1+RBFXEnAoSozN/6vnnc5n AR08v4WMaB3vdgOxFQWsUYLNfYYwZtZOW2ZjrCAbkvSS/RO+VaS7/xrAWVooRz2tqRyF ABH6rSYo+Xq5n+jMc3oLWWaP6C8SKRIxc11CalczFWSunI7lvgzh152U/LfIK3dkhIR4 2+sGzS2y9boTfR5e0Y/E4WZqXb/nngZFcoptwihk+RqGVkTEasNSUS1zo6F4Co0lIzzQ 53puYErpyswX3lAcmrg8dYlKAUUkjmi5viciZvJq/A+c3klpFIXs7InMag6BychfcZQq yPtA== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Return-Path: Received: from david.siemens.de (david.siemens.de. [192.35.17.14]) by gmr-mx.google.com with ESMTPS id a15si788739lfb.3.2020.06.22.01.09.12 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Jun 2020 01:09:12 -0700 (PDT) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.14 as permitted sender) client-ip=192.35.17.14; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by david.siemens.de (8.15.2/8.15.2) with ESMTPS id 05M89BRB007285 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 22 Jun 2020 10:09:12 +0200 Received: from [139.22.110.241] (wpdkn10-01941.ad009.windad.org [139.22.110.241] (may be forged)) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 05M89BEN009816 for ; Mon, 22 Jun 2020 10:09:11 +0200 Subject: Re: [PATCH v2 1/6] sdk: Add support for adding self-defined sdk packages From: Jan Kiszka To: isar-users References: <474ed5e64a311c861761d46a723e1bfef3bab973.1585394686.git.jan.kiszka@siemens.com> <392d9aec-1b35-b9e5-3ad6-c6b2f1b7a102@siemens.com> <20200612093446.GQ5077@yssyq.m.ilbers.de> <7e96e51c-6884-a472-fb16-cf693e091356@siemens.com> Message-ID: <75135098-339b-39fb-7ce2-39eac52b237f@siemens.com> Date: Mon, 22 Jun 2020 10:09:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: fR2ionjCYVN2 On 12.06.20 12:05, [ext] Jan Kiszka wrote: > On 12.06.20 11:54, Jan Kiszka wrote: >> On 12.06.20 11:34, Baurzhan Ismagulov wrote: >>> Hello Jan, >>> >>> On Mon, Jun 08, 2020 at 12:22:26PM +0200, Jan Kiszka wrote: >>>> I just realized another design issue with current sdk building: >>>> sdkchroot is shared with all image recipes that request >>>> do_populated_sdk. You may expect that defining SDP_[PRE]INSTALL there >>>> would have any impact, but that's not true therefore. Only adding those >>>> to an appended sdkchroot recipe or the global configuration works right >>>> now. As these additions may very well be specific to individual target >>>> images, neither of those options are perfect. We rather need to make the >>>> sdkchroot specific to the target image requesting it. >>>> >>>> That said, such a rework could happen later because the current form is >>>> already fine for a lot of use cases (and is being used for a longer >>>> while now). >>> >>> Thanks for the heads up, this was not on our radar. Let me check it and get >>> back to you. >>> >>> Our comments so far: >>> >>> 1. I think the series is a good improvement, thanks. >>> >>> 2. isar-apt is added to the SDK so that the developer can install anything >>> after the initial preparation of the SDK. E.g., the user has SDK_INSTALL += >>> libhello-dev but during the work he decides to install also libbye-dev using >>> apt. I suggest to keep isar-apt configured unless there is a better solution >>> for this use case. This also implies that we should keep both approaches -- >>> relocate and chroot -- usable. >> >> If you want something in the SDK, add it upfront, via patch 1. Shipping >> isar-apt is pointless bloat. Therefore the removal. >> >>> >>> 3. relocate-sdk -r puts two slashes into the binaries. Also, strictly speaking, >>> it doesn't restore the binary into the state it was before, since rpath was >>> not set by default. Should we just remove rpath instead? >> >> Of course, we could also remore rpath. Does it practically make a >> difference? >> >>> >>> 4. It is also possible to set rpath to a relative path (in combination with >>> $ORIGIN). In that way, the same SDK would be usable with or without chroot >>> -- the use case is e.g. #2. >> >> How does that work then? Would we have to set rpath relative to the >> respective binary location? If that worked, it would completely obsolete >> a runtime script, right? > > --set-rpath > '$ORIGIN/../../usr/lib:$ORIGIN/../../usr/lib/${arch}-linux-gnu' ? That > would be cool... > > >> >>> >>> 5. I'd suggest to drop "recommended" and "fallback" from README.sdk. >>> relocate-sdk is already listed as the first option. The rest is a matter of >>> developers' preference. Or is there a specific reason to prefer one? >> >> It's not just a preference because the chroot is more involved, requires >> privileged and prevents many SDK use cases. Therefore this clear >> recommendation. >> >>> >>> E.g., I personally use chroot to avoid host environment leakage into the >>> built stuff. I'd like to work on the host, but in a Debian way (think >>> multiarch -- which IIUC currently doesn't support amd64-stretch on >>> amd64-buster). >> >> The whole point of the SDK is to enable easy application development. >> Production builds would come an Isar environment, or a package builder. >> You surely do not want to tell an ordinary developer to use sudo chroot >> for daily application building. >> >>> >>> 6. rpath and wrapping doesn't address all use cases. >>> >>> 1. Shared libraries may use other shared libraries. >>> >>> E.g., ffmpeg fails to find libopenal.so.1 if >>> usr/lib/x86_64-linux-gnu/libavdevice.so.58 is not patched. >> >> LD_LIBRARY_PATH >> >> We may need some env tuning script for that. >> > > Or can we simply include the libs into patching? > Any idea on that? And what exactly did you test? > Jan > >>> >>> 2. Binaries outside of bin are not patched, e.g. clang-format. >> >> Then let's fix that. Not sure if that need to be in scope. If you look into a cross toolchain, you find -linux-gnu-* binaries, and this is generally sufficient. >> >>> >>> 3. Wrapping doesn't cover e.g. arm-linux-gnueabihf-gcc on qemuarm-buster. >>> >> >> Then let's fix that. Trivially fixed now. >> >>> What is your vision on this? I think we will never cover all possible cases >>> and should rather strive for a working subset -- which your patch provides. >>> I also think this should be documented, because I assume that Yocto SDK is >>> not buggy in this regard (manual usability due to -isystem and stuff left >>> aside) and encountering such problems with the Isar SDK would be a bad >>> surprise. >> >> The vision is clearly to resolve the remaining issues. It will be a >> product feature and the way we promote the SDK. chroot is for legacy >> only, may even be phased out eventually. Then we can remove also all >> those unneeded debian tools from the image, only providing the compiler >> with its libs. >> > Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux