From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) by sourceware.org (Postfix) with ESMTPS id 76D933858421 for ; Wed, 19 Jan 2022 19:52:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 76D933858421 Received: by mail-oi1-x229.google.com with SMTP id bb37so5961649oib.1 for ; Wed, 19 Jan 2022 11:52:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:to :content-language:from:subject:cc:content-transfer-encoding; bh=wh/G+P1TnNoidmrqkUsDHE1XvcUCQ+mXRruuvtXcER0=; b=H1zPccbQUvvTzz/kjblBKJjzZwCCSWKrxW4cYpK/iQL0wFOBbCHyhIkaBeoBEHBvYA 0pozsCopFmo6Hb15r+NHipLIs/WLICYahN9DArVLrgCszBDAy3hflHC8pmVU6tgQCQrm zT9OfNxk75uN13X99b4udNAA/uAYxrUR7jRBXg38FuaVBaZ88iKIItLI3ObSua8A3abh aY5+qlhE1oEmyV2pOaU3JWI1iHfD1l7eCH+RDK12oZ4xA/5ognx8/pgEat/iiGvIn+A0 HQn/SM/NBIGPEJ7LyOQ87syk1wrmeTOfp3azhP5GIInuFlwY56y+A0Rz+IbrkyIh0S7j +LZQ== X-Gm-Message-State: AOAM530nUuj2jxoFHi6nizCKfm/80KKwPFBPWulkLQ7AodoHJp0WborQ 2V7bDis7VMheuofg6EQBDH6Yvg== X-Google-Smtp-Source: ABdhPJxMzmd6LCaKl3MRueUSWBXRg6TrCb8jnEAzJK1bW3bzmVn1xKI9XDJ9Vx10hhbZtzmpI79/hg== X-Received: by 2002:a54:4e9a:: with SMTP id c26mr4458989oiy.159.1642621959552; Wed, 19 Jan 2022 11:52:39 -0800 (PST) Received: from ?IPV6:2804:431:c7cb:989a:7856:7c09:a19c:8c7c? ([2804:431:c7cb:989a:7856:7c09:a19c:8c7c]) by smtp.gmail.com with ESMTPSA id m23sm354852oos.6.2022.01.19.11.52.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 19 Jan 2022 11:52:39 -0800 (PST) Message-ID: Date: Wed, 19 Jan 2022 16:52:36 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 To: Nicolas Dechesne , Carlos O'Donell , Libc-alpha Content-Language: en-US From: Adhemerval Zanella Subject: Yocto prelink status Cc: Mark Hatle , Khem Raj Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00, 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-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2022 19:52:43 -0000 Hi Nicolas, Siddhesh told me to contact you since are involved on Yocto project. Recent discussions on glibc maillist about prelink supported is leading us to deprecate and remove its support on glibc. Last year it was hinted that Yocto seems to be maintained the project, although without much development [1]. A recent issue [2] with a change to support llvm lld to build glibc lead to a issue when prelink is used on the loader itself (which does not make sense since kernel will be responsible and it does not really care about prelink). Finally the discussion on a recent patch proposal [3] to fix an issue for sym dependency makes me believe that prelink is de facto deprecated, since it does not work on most binaries in most architectures (20-30% of the system is capable of prelinking according to Mark) and it tends to get worse with new ABI extensions (for instance we plan to support DT_RELR on 2.36 [4]). For instance, prelink on a Ubuntu 20.10 on x86_64 prelink -p shows that no binary could prelinked. Mark also stated that for embedded prelinked still yields some gain for loading time (specially for system boot) and memory consumption (although I am not sure if it really yield any gain for recent ABIs that avoid design such TEXTREL and writable PLT). My plan is to remove prelink support for 2.35, at least to stir some discussion. Unfortunately I don't have a straightforward replacement, I see prelink as very narrow solution that aims to fix some glibc design drawnbacks (such as not being focused for static linking, neither to lower memory consumption). So I would to like if Yocto plan is to continue support prelink somewhat, or if you have any other ideas. At glibc side, we are trying to fix some long-standing issues related to static linking (we deprecated static dlopen, and we working on the NSS support), but it still required some work to be on par with other static oriented libc. [1] https://sourceware.org/pipermail/libc-alpha/2021-August/130404.html [2] https://sourceware.org/pipermail/libc-alpha/2021-October/131989.html [3] https://sourceware.org/pipermail/libc-alpha/2022-January/135189.html [4] https://sourceware.org/bugzilla/show_bug.cgi?id=27924