From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) by sourceware.org (Postfix) with ESMTPS id 85B2A384607B for ; Fri, 20 Aug 2021 14:37:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 85B2A384607B Received: by mail-wm1-x32f.google.com with SMTP id u1so6129694wmm.0 for ; Fri, 20 Aug 2021 07:37:59 -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:user-agent :mime-version:content-transfer-encoding; bh=G8fbLaPHhWg9+HJaNgtC2Vlh6rQkfMmTItNnAGn3KT8=; b=TSTEXFEYZrSp8yPETruinpvecBvbIYp2fspDXHcIVHm/f5L9arPDL2moAAF2fIuPT7 nku9vZR+t7phKgsSMWT3HCW/r6DVK9acN4utf2/H1PiPwVJkw+Rzkaoi5mDqHtC1mVBE 6zBXyl3wLuShleF4u9dyRQ2575Qtnl9fyXbkpg+4pZCtXxezppI5Eu52oawHk4ljrk4S /qZ/ScTYycJpmAGen5AspVJGUMxOyEu5qvRTzy3n/aaJZfgTFkHxKiSqOAaQek9Jm9YI so+bO+8rKmNAuC+3jfyUZk+2iBBhECTj8QiAsVtHwJhloUR7usV27Bo6QNxY1vj7u/Wu r2zA== X-Gm-Message-State: AOAM533SBqmQKGzhaj90el+Hloh+gSxITFyz+aj7vK2fwnTKllALICeJ vyiKx4J8mj3x01OdcWZn5FJxzNjSyqTETA== X-Google-Smtp-Source: ABdhPJyamjIna0OdEmDxMrHzuHuW2fCb2bhBBaW65cVb4EDo7dnZKWFZQHhee4UQlaybbRnOvdTI9g== X-Received: by 2002:a05:600c:4ba4:: with SMTP id e36mr4452625wmp.82.1629470278533; Fri, 20 Aug 2021 07:37:58 -0700 (PDT) Received: from ?IPv6:2001:8b0:aba:5f3c:be98:6fdb:15ff:ca52? ([2001:8b0:aba:5f3c:be98:6fdb:15ff:ca52]) by smtp.gmail.com with ESMTPSA id p12sm4852162wmq.44.2021.08.20.07.37.58 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 20 Aug 2021 07:37:58 -0700 (PDT) Message-ID: <978104bdbebcd09d159f1713499cf1315edf40f2.camel@linuxfoundation.org> Subject: glibc 2.34 and Yocto Project's "uninative" From: Richard Purdie To: libc-help@sourceware.org Date: Fri, 20 Aug 2021 15:37:55 +0100 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=-1.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, URIBL_BLACK autolearn=no 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: Fri, 20 Aug 2021 14:38:10 -0000 Hi, Yocto Project is a cross compiling build system used to build customised Linux, RTOSs, firmware and more. It has some interesting technology. One piece of it is "pseudo" (http://git.yoctoproject.org/cgit.cgi/pseudo/) which is an LD_PRELOAD which intercepts calls to libc and fakes root privileges. One way or another we've managed to keep that working with multiple libc versions for the last decade. A second piece of technology is uninative. We build a lot binary artefacts, some for the target, some as tools running natively on the build system. We have a cache of these artefacts people can share and reuse. Uninative is our way of allowing one binary to run on any host distro. We do that by shipping a ld+libc binary shim and change the interpreter in the native binary to point at our own. As long as the shim is the same version or later than system version, it works. In glibc 2.34, the merge of libdl and libpthread into libc is causing a problem for us. Basically, I've been able to make pseudo work and I can make uninative work however I can't make them both work together with glibc 2.34. Pseudo uses minimal dl calls from libdl (dlsym, dlvsym and dlerror) and has a pthread mutex, therefore it links to -ldl and -lpthread. The issue is that pseudo being an LD_PRELOAD, if linked against glibc 2.34 doesn't "see" symbols in libdl and just links to libc. I did try forcing older versions of the symbols along the lines of: __asm__(".symver dlerror,dlerror@GLIBC_" DLSYMVER); __asm__(".symver dlvsym,dlvsym@GLIBC_" DLVSYMVER); __asm__(".symver dlsym,dlsym@GLIBC_" DLSYMVER); with some arch specific version number defines however even if I do this, and put back a libdl.so symlink to the lib, the linker ignores the weak wildcard reference and links back to libc.so itself. When we then use this preloaded lib on a system with an older libc: relocation error: [...]/libpseudo.so: symbol dlerror, version GLIBC_2.2.5 not defined in file libc.so.6 with link time reference I did try ensuring libpseudo.so has a RUNPATH that includes our uninative libc however the loader ignores that for loading libc. I did then add our uninative libc path to LD_LIBRARY_PATH however that fails: libc.so.6: symbol _dl_exception_create, version GLIBC_PRIVATE not defined in file ld-linux-x86-64.so.2 with link time reference since the ld being used doesn't match the libc. Can anyone see a way we could make things work? Cheers, Richard