From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6806948680239677440 X-Received: by 2002:a1c:9dc7:: with SMTP id g190mr13334666wme.129.1591954490236; Fri, 12 Jun 2020 02:34:50 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a1c:a70e:: with SMTP id q14ls2336225wme.0.gmail; Fri, 12 Jun 2020 02:34:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyRu1qAaO4jWdnUskcbmHvALjWKLJEzY+BrXaQ5fq17y1/zmYdsqC/TbdDoCE3hIRuJ60k2 X-Received: by 2002:a1c:740e:: with SMTP id p14mr13204018wmc.155.1591954489728; Fri, 12 Jun 2020 02:34:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591954489; cv=none; d=google.com; s=arc-20160816; b=WX4olFrpyy5oS4PSUzIQ4XWaciKAzmvv0K7HZGzJ3NfX0qO/iCLvd6ZvAxlcOhz85v 8s1BtRFqrC4/zaVmdW0EqpFPyy5RgYFSmITxSxvPRvMzfUdFOG2tYOveUNfqOOttb/9L nOe8FvAA7kh+izxiMKGz7q7XnVYqQd5TWV/TskKCm+Og+6CGvsYNLBM4PT3+oyPPkcwm cXPpin72u8lIUUW5QUGR8fwSFY0S7NzyqPRtBQcCwRVyraghUQA0ByYtQCGF4QXji7ir 4xdyRKipbQEUZ7fKCAPzeIFe2qQOUfwi388MYZ22qtr03nmLymEpyZhHDNLwM1+Im/8F AhCA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:to:from:date; bh=+cfBMkMtcgNQjh5WkD24bCVs/8onLmQ7+omzYe8kXSg=; b=esn27SqMnsfdlD3GrubMBpLHya9QWHrs4WFzELMCjw/2X9PyF90OjTsR69BDlIJfIR ycAnPbtHeOWBP5VM1sGijwxaAczlifjmxJ84G+S9zcisVdMLE4l5WHgAzbcwbhbcDxDB bro9WAFBAVShB234DgLavaBIfP/cd0nd4ewmT7+4niipl7nbbH8Y48MZv4VNmGxxhkcd sk72uH7HSB7bUix/TZ845whjXChw7M3WuArb2p4hgQ5AwOlAv7sgX2IybEz7fi+N5Epp KjmxtFl9he98Mdlpcr4glWQuYb/7EGUdIZFsjZVqqc6eKc7HoLU/AF1SxvgXTaQwoegV XeMQ== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 85.214.156.166 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) smtp.mailfrom=ibr@radix50.net Return-Path: Received: from shymkent.ilbers.de (shymkent.ilbers.de. [85.214.156.166]) by gmr-mx.google.com with ESMTPS id r204si618725wma.1.2020.06.12.02.34.49 for (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Fri, 12 Jun 2020 02:34:49 -0700 (PDT) Received-SPF: neutral (google.com: 85.214.156.166 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) client-ip=85.214.156.166; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 85.214.156.166 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) smtp.mailfrom=ibr@radix50.net Received: from yssyq.m.ilbers.de (host-80-81-17-52.static.customer.m-online.net [80.81.17.52]) (authenticated bits=0) by shymkent.ilbers.de (8.15.2/8.15.2/Debian-8) with ESMTPSA id 05C9Yk5O027343 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 12 Jun 2020 11:34:48 +0200 Date: Fri, 12 Jun 2020 11:34:46 +0200 From: Baurzhan Ismagulov To: isar-users Subject: Re: [PATCH v2 1/6] sdk: Add support for adding self-defined sdk packages Message-ID: <20200612093446.GQ5077@yssyq.m.ilbers.de> Mail-Followup-To: isar-users References: <474ed5e64a311c861761d46a723e1bfef3bab973.1585394686.git.jan.kiszka@siemens.com> <392d9aec-1b35-b9e5-3ad6-c6b2f1b7a102@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <392d9aec-1b35-b9e5-3ad6-c6b2f1b7a102@siemens.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on shymkent.ilbers.de X-TUID: eDnKB/plNGpB 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. 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? 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. 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? 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). 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. 2. Binaries outside of bin are not patched, e.g. clang-format. 3. Wrapping doesn't cover e.g. arm-linux-gnueabihf-gcc on qemuarm-buster. 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. With kind regards, Baurzhan.