From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6806948680239677440 X-Received: by 2002:a1c:7f44:: with SMTP id a65mr13293384wmd.53.1591957806394; Fri, 12 Jun 2020 03:30:06 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:adf:82ce:: with SMTP id 72ls3725695wrc.1.gmail; Fri, 12 Jun 2020 03:30:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwXk3N2JM3lmdo89fJAXxWILRA0bh+g7VfIpwIgAicuRH0X9fbL8ZWrUNaqgd9m0YK9+MJz X-Received: by 2002:a5d:690b:: with SMTP id t11mr15340261wru.213.1591957805667; Fri, 12 Jun 2020 03:30:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591957805; cv=none; d=google.com; s=arc-20160816; b=TGbLA3geZ/k98lZvwXup7Ze7XiSlaGTaIaSOaNF1mUC1Hr6r0pz1aDIJbCiyGmiRyj tD1hRhPAUG2OJZLD8/9If1HdvG7VoJDnByEsUQy+dJ8X45v6K5YBUeq+d0/2PTX9BmRO On+IPudFDY26b1ob8ej2kGRG/99ikQ+QmIHWQ31ddwHsErnvSSoBJhu9HLhhIZP8nLXZ jmHsM/HXVvQXPt63XY5MezA+GXMw/cEPBB07OAcJ4msXICNI24AMNNOiiqiEuzibYl4U bQnipV4F+6/y0fDF8PJUuCvfxgPbKfFxZkIH2cBxzPKFS9zih4mxcAS8AIOlk1A56ytg BjMw== 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=Mf5/ZGdp4L1rvkQGQ7XbTg97ddNvoO3pmj0pi2r6o2Y=; b=ySR9dVDx9RCU5rl756+34/gggwV+LfKJubeDh71Ah+HZUcl7khYJy2Mfeud/AXwRk9 dtf8RcAOD2KwDovUeofK9trRIvV5JnYw1EHTK6iMs/87VqHDiB3inAj7469D9fNMcQGn ryfxRGljAqR3z1hGbkXizAcBKSexRpjc7JMv9ATCY5wIT5EAZvccSEEFXqpn0ATx0UUV HSH0T1RL18/kiEhIyas4w1iUMLP3Zdn2wFYolyAY6us7z1BVoZfjSBs2F1A308+qhG7s w7DIV/za1oZrRQ3glsyd+vHDw/PCPBExwLsDlRVh7xlNaznskxIb7VaMUWGpOaCPuAMy Umgw== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.28 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 goliath.siemens.de (goliath.siemens.de. [192.35.17.28]) by gmr-mx.google.com with ESMTPS id l4si389818wrc.0.2020.06.12.03.30.05 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Jun 2020 03:30:05 -0700 (PDT) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.28 as permitted sender) client-ip=192.35.17.28; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.28 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 goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id 05CAU5Ko023959 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 12 Jun 2020 12:30:05 +0200 Received: from [167.87.11.220] ([167.87.11.220]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 05CAU4eO008809 for ; Fri, 12 Jun 2020 12:30:04 +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:30:04 +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: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: lRCKzKWGylQH On 12.06.20 12:05, 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... > Yeah, would have been cool. The interpreter is biting us: https://stackoverflow.com/questions/48452793/using-origin-to-specify-the-interpreter-in-elf-binaries-isnt-working Just realized that I've been there already. Jan > >> >>> >>> 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