From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6806948680239677440 X-Received: by 2002:a5d:49cd:: with SMTP id t13mr15243945wrs.292.1591956343716; Fri, 12 Jun 2020 03:05:43 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a1c:1d84:: with SMTP id d126ls2388299wmd.1.gmail; Fri, 12 Jun 2020 03:05:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwlnH250eoEVRwwcxV78lY12eLsENSLNqrpTioZcvkqQvcngW8e2b34mGr2+Rl6Tr81DIwN X-Received: by 2002:a1c:3987:: with SMTP id g129mr12561647wma.139.1591956343049; Fri, 12 Jun 2020 03:05:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591956343; cv=none; d=google.com; s=arc-20160816; b=yj7AyodwDnM3ccKnjqZzgK+Dru2bMrxK4MjgzsL+LlSURc0oEJVwqnenbC5PuyFlH+ W+YAqPBKDJgfHXvqp8FMsfy4JvJpFVfzdzKrR3s9rC957uRmsBtFhtjDxXgk0KSIczWf mV4wfsIec+zD9fki56bPf0MXF5daAG4KsUqwb3dGSJuaVmUlBXQoK4ewK4scdUCmBVR7 fKB3d37KmrQxtbT4NaC6jzBZwOTvf7q7QQIeLhI34wp1z88jKLhM6nli8qCyhGBTnLPx BmlqlvIf24DjYk6xHYL60LEGfpZHvINetxumIJq2QI5ecCGn5HyuK1c5bCYvVM/3pDXw fHqA== 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=XGhTqg5ALjAKrDTUOoZCee46vxn8cYynfcYlm9kKQMo=; b=J5dG0LTZ4tN7A5gFuN7CcYSAwyh2aOThNEg1Kk9LmZ7N8mIsTD/nP4afQX/IpohvdI 9NHNzHoXPe0LxexEnI7ie96Bxw2+Lg5pKOIpw0t+8U47bOLSb3tWywbGfPR0+rwySqw0 eeR0+F0ic9QQJd6XgMgXjutuxKVcZLs1uxfleGAqaz8P3QJ9UtoqCy49wMZly6pa4sA+ doiT5NBmkhj6jNNS4Rx/ee3kyYLzPGrTy6n7bVv2qQGJJHMlM/wvf3Z0hauVp9rvqzR+ Ifn3JYd/tpc7ewZrGP2Taj2FMTObgePskuVigy5mgNy9Ae2H20jBkY+52PUGnFKHGyUN gh8g== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.2 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 thoth.sbs.de (thoth.sbs.de. [192.35.17.2]) by gmr-mx.google.com with ESMTPS id w126si715255wma.4.2020.06.12.03.05.42 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Jun 2020 03:05:43 -0700 (PDT) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.2 as permitted sender) client-ip=192.35.17.2; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.2 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 thoth.sbs.de (8.15.2/8.15.2) with ESMTPS id 05CA5gIZ020407 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 12 Jun 2020 12:05:42 +0200 Received: from [167.87.11.220] ([167.87.11.220]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 05CA5fNF016988 for ; Fri, 12 Jun 2020 12:05:42 +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: Date: Fri, 12 Jun 2020 12:05:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <7e96e51c-6884-a472-fb16-cf693e091356@siemens.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: NJkeItirD2rq 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? Jan >> >> 2. Binaries outside of bin are not patched, e.g. clang-format. > > Then let's fix that. > >> >> 3. Wrapping doesn't cover e.g. arm-linux-gnueabihf-gcc on qemuarm-buster. >> > > Then let's fix that. > >> 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. > -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux