From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) by sourceware.org (Postfix) with ESMTPS id 971CA3858C27 for ; Thu, 26 Aug 2021 11:29:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 971CA3858C27 Received: by mail-wr1-x42b.google.com with SMTP id u9so4477349wrg.8 for ; Thu, 26 Aug 2021 04:29:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=wwGAIhZ2X6b8Zpl5JdxbvclivGXAnFFI3Dp2e/YKNUI=; b=oqFQf+D0kZWjFJJ0CXLNoyVCnzigYNyoun87tuvJqxITCS2y6KLak1RsPNbFTJLIuy b0jo5QJe6gFHs/z81qZTziuExjUV1m1W0mWWrLNL861eNPp0BUFB043n1ovnTSFGfVsl QWh3fOEINBzBNlql1BM+u9Ragh28Jah9UG1BoyUqT0uuHL05eZXM1GpfUxrC1OEKz/h7 Zcn7Wf/jc8oQaFgIF1rypKQUKdpzyZjKl1tcq3FksR2ilRVu1FKMRuQL8UxwedH2UANe TmE7Ft1LBbexauItgZ0KgpS0nLG3gqBAILajDRAcf4g/LO2kiEXlzhmNZ1uMsDPl6ca5 1j2Q== X-Gm-Message-State: AOAM530DW8m5cU+mPrmjKCGm3Vk+VKTYkUjBxf5U6Vba7ex5P48su/EF c6L52DljszipPF4uXUlVDowxJCfB2zB2wQ== X-Google-Smtp-Source: ABdhPJx1IdTw6AjOKDojNz7wR0odWAjdtKWeHLuy4doY7wilXqRxk7eOn2A5yz9kjPohodVuj2akNg== X-Received: by 2002:a5d:464f:: with SMTP id j15mr3381399wrs.325.1629977360762; Thu, 26 Aug 2021 04:29:20 -0700 (PDT) Received: from ?IPv6:2001:8b0:aba:5f3c:a9d5:4a4f:480b:62d4? ([2001:8b0:aba:5f3c:a9d5:4a4f:480b:62d4]) by smtp.gmail.com with ESMTPSA id d9sm3558528wrb.36.2021.08.26.04.29.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Aug 2021 04:29:20 -0700 (PDT) Message-ID: <90cdee71fbc174e85c43e2ae3a05d735e0b36715.camel@linuxfoundation.org> Subject: Re: glibc 2.34 and Yocto Project's "uninative" From: Richard Purdie To: Adhemerval Zanella , Libc-help Date: Thu, 26 Aug 2021 12:29:19 +0100 In-Reply-To: <6d63802a-dc3c-e2de-8db4-a0ec92bbb9f6@linaro.org> References: <978104bdbebcd09d159f1713499cf1315edf40f2.camel@linuxfoundation.org> <4224ac85-83b7-6fe8-6781-b8e8f514924a@linaro.org> <55b147c8807abe56c41670b6c3e20fdbec85f291.camel@linuxfoundation.org> <6d63802a-dc3c-e2de-8db4-a0ec92bbb9f6@linaro.org> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.40.2-1build1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 11:29:32 -0000 On Thu, 2021-08-26 at 08:16 -0300, Adhemerval Zanella wrote: > > On 25/08/2021 17:11, Richard Purdie wrote: > > On Wed, 2021-08-25 at 12:05 -0300, Adhemerval Zanella wrote: > > > > > > On 20/08/2021 11:37, Richard Purdie via Libc-help wrote: > > > > > > > Can anyone see a way we could make things work? > > > I don't have easy library based solution for the requisites you posed, > > > building a newer glibc and running on a older one. I think what *might* > > > work is to provide a auditor library linked against the newer glibc and > > > it then intercepts and routes the required library calls. You will need > > > to redistribute the libc which the auditor was linked against. > > > > The other libc is already there so that bit is easy. I hadn't thought about > > using an auditor library and I'll have to explore that. > > The auditor interface work on some examples, but unfortunately we also found > that they are fully correct on some more specific cases. We are aiming to fix > for 2.35 [1]. > I have to admit I've not used the auditor interface before so I've a little learning to do there! Thanks for the pointer to the patchset, it is handy to know there are known issues. > > I was going to go down the route of dummy libraries to link against however I > > realised it was easier for testing just to pull down 2.33 binaries and use those > > to link against. I did have to replace use of pthread_atfork with > > __register_atfork which is ugly but probably okish for our use as it has been > > there since 2.3.2. > > Yes, this is what I would suggest you (use an older glibc to link this against). > > > > > That probably gets us out the immediate problem although it does highlight we're > > doing something that isn't supported and could break again in ways we may > > struggle to fix. We can probably replace the pthread linkage for the mutex with > > direct code/syscall usage. We're going to need the libdl usage regardless though > > so it may be worth us figuring out the dummy library to link against for that > > piece. > > Why do you need to build it on a recent glibc and potentially use it on an older > one? > We build standalone (and relocatable at install) tarballs of tools that can be used on older distros to support our builds where we need newer tools such as binutils/gcc/tar. We build most of our binaries against a recent libc and then include a libc in those tarballs. We also support sharing of our "native" tools amongst ranges of host distros using our uninative mechanism which involves changing the interpreter to our own and using a latest libc everywhere. pseudo is our fakeroot intercept that works via an LD_PRELOAD. We build that against our own libc as with everything else and it will likely be more recent that the host distro it runs on. We can't change the interpreter of binaries from the host distro but we do need to still intercept their libc calls and it will end up in an environment where the libc versions can be mixed. As such, the preload portion of pseudo needs to run against older libcs. Cheers, Richard