From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6806948680239677440 X-Received: by 2002:a19:f515:: with SMTP id j21mr1783376lfb.134.1591955674370; Fri, 12 Jun 2020 02:54:34 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a2e:998a:: with SMTP id w10ls1093825lji.0.gmail; Fri, 12 Jun 2020 02:54:33 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzY3Dy8x3SRDWj10rbQg7tf9QrHzWJFH2NAztlAIy38Uo4XkbqYZmh0QfRLv59wjCuHoUTk X-Received: by 2002:a2e:9804:: with SMTP id a4mr6856728ljj.369.1591955673499; Fri, 12 Jun 2020 02:54:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591955673; cv=none; d=google.com; s=arc-20160816; b=fDrDvxB3PNPvP7dDUKmPRc2oOLfFssOpJAPqtouCY6Af495fXvipvEYvWKaG/ufNgD n0oBcFt5JVWV3Ungb/GprhbLuEanEVFyrg2wW62PNLdnTrj8HH3PLitRnKlDH2UjyDd3 VmYaslLyEDo4p4uEQvECnPmpCeCDt1YBCPDDs7yyeMNmJBFVSGKGlAWKavDZDFMCBOLh C/TMsg9dlKVSzWNMG9xIq6Q+/ZmURCMR5bkq6iPBDVkP5xMIDKfkO+e03DTnhyGl+4fa CqbqMUMx66Ldde0J0Jn2ds8hFQCISTQdeArj5sVTpknChjrY/mA1c2YaR8IMPuojUYdT s6MA== 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:from:references:to:subject; bh=j3mlb/rsNCJfsfXemmp2fhpdggtkYTKZ8rorleR7BJw=; b=W+u+7cc1g44xNG6C/7w3r8sxPKcHK7e1jkOr9UdCT2T0S3ULGGjN6tiscBJwsBJyh4 nO4mSisViOdbRUhQgnotvwCe9UyyE3jIuNRH/eWIkRPkr56bgCGjfADlxS4FaePVSdUM 3H/jLEZQKhL55mBH1uVI/U9NkSQ9XlOeh9ppmP/Omn+JXEqgAp+kh2Qrsr7vvqkwaBre eRoGvGpLgmuXp4qXiZdoJ56syJadtWqrtQ6KnzdSlDyAPuNN8kXQ5VeAQQiWFrYug8+j SHfkrbXL8tukNSCew/NR5Hx2E2xUBP3aN7ZZH4625DH/BMEV+MNhNbXk3slDq5+izmjU TMwA== 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 130si289561lfi.3.2020.06.12.02.54.33 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Jun 2020 02:54:33 -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 05C9sW0M030186 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Fri, 12 Jun 2020 11:54:32 +0200 Received: from [167.87.11.220] ([167.87.11.220]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id 05C9sVYG005676 for ; Fri, 12 Jun 2020 11:54:32 +0200 Subject: Re: [PATCH v2 1/6] sdk: Add support for adding self-defined sdk packages To: isar-users References: <474ed5e64a311c861761d46a723e1bfef3bab973.1585394686.git.jan.kiszka@siemens.com> <392d9aec-1b35-b9e5-3ad6-c6b2f1b7a102@siemens.com> <20200612093446.GQ5077@yssyq.m.ilbers.de> From: Jan Kiszka Message-ID: <7e96e51c-6884-a472-fb16-cf693e091356@siemens.com> Date: Fri, 12 Jun 2020 11:54:31 +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: <20200612093446.GQ5077@yssyq.m.ilbers.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: JvKLztHXr+1k 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? > > 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. > > 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. Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux