From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.com (mout.gmx.com [74.208.4.201]) by sourceware.org (Postfix) with ESMTPS id DEFC63858D33 for ; Mon, 17 Jul 2023 23:13:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DEFC63858D33 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=mail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mail.com; s=s1089575; t=1689635618; x=1690240418; i=rozee@mail.com; bh=IUmQWkzz8ii1CWYDMhk/AqGhXrxjqUwS/+kG60HE43c=; h=X-UI-Sender-Class:From:To:Subject:Date; b=PgM/Nj/lmtwwy1nQJwp6U6BvbsJnUnctTCuw7lVDfqwU+n9odV815ZLf/zNAiyfVQUbQOEb 7c0RtYFKZxIpvJX1AXgMdtNF8r6kc+LsFQ5cyo6ejkmPNUpGYvlKV2FIJsuNa0nFdqP7CAkhQ 0CBj4lof52fPQsty6l8ourIDId3HVs3Thgk8UiK0KGhhkoq59kxQRkL2Zpqm4IoO8lNT337f1 km8OJyn8CWlMa68ZfK7w2MXd/Af8imnpO+LuixSisgO4yhqYUr7we2hLW7fDvV1TQZ5+Qh4AF MZgDLIUmcXW8HLcCmYqRBkKDJZfTIJJO73YW88bfiX95fPIhfuPg== X-UI-Sender-Class: f2cb72be-343f-493d-8ec3-b1efb8d6185a Received: from [119.224.41.171] ([119.224.41.171]) by web-mail.mail.com (3c-app-mailcom-lxa06.server.lan [10.76.45.7]) (via HTTP); Tue, 18 Jul 2023 01:13:38 +0200 MIME-Version: 1.0 Message-ID: From: robert rozee To: libc-alpha@sourceware.org Subject: question of compatibility between different GLIBC symbol versions Content-Type: text/plain; charset=UTF-8 Date: Tue, 18 Jul 2023 01:13:38 +0200 Importance: normal Sensitivity: Normal Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-Provags-ID: V03:K1:ayexwW/g4wVaO03AuLUIj7NZk7Cb0fu7x3gurfMw3Y6Wnhmb/RFjsBAxBU2h37PsfYt20 8IX3vijZO4av3bax51gQvA/iCi329LmCI6ij8RqlQO6F7xGpFrZm5GyeOKlAH6WCADc8TOFRshkl dMtgERbnDFXUkHHBnCcQpfiYGTlhHBaPJeYysfwsq8salj/+3newCRDUzf4yna3NloOkacdKDjEZ jYRpuHTyTc1v+SrHwgA+t18tAxnL9N9FwzNemkKT0TDjf30Ki0Tl6mBieDYtvrOLwLxfEU8iJVsa cQ= UI-OutboundReport: notjunk:1;M01:P0:DKyH1puujck=;d4aFyfP2AZRxp5UaoRMEuW4zaHr kayAkMyiU+ypZZIBxuGpNBPJxckZhtR/xZPKFwUCdT48MULg0sDiHy4hRoCr+7WS4/aKzyFxl VvCHctAgJ6PcPH7u2isYNcVxb4vyts6eH6f/EtsgkRTzpv2lJwdxVDX4gqVjQbXJPM/CVaqW1 A1+wMmdXXC4MxTocux1uwV4ENjCNB9m82SInj0NR4f7axas3r1+h/RN8wA7SGkCHmePw9ZecH E6SK3RPq+BxHQjBDvrX2O068j4xv1UliEO7l73rh79E03szsPo9YR8zECjrQrp/SKB3CbM7rx uLHKDooULSOOMQirXvey+YIGgV6GggYAhk74ovgqf7ikLHvBbS7oEvBIqq8oljdWJjkmu/jCZ iDZTo1dZgvpl53THd53e7pfbbEYMhJqMsK7NAEdcrxryKSQO3cg8zEx26xbllEHOsojZUSMCk IAcITV7zz/6w4tK0mUh26rznpQW1edYDehzOURiQ23Qc8F1MdfiAwiCEzcpOAEUp4C6VlCzwk BTKUAlzbHyqUQntE2CcwZYf3r7LGTZS0CcDPG7yc7s0fP8/QHhi14UsbnYP6hLCZdyq+u11+X aQDPbJkZ1dncKwcjGknH0dEVSNQjjPt0MQHSgLIKigTVI7F4AAVi5CJwfUWEuPBkNECi0FC/6 c1i+ue3xp22eWcVz7E+fxO9C90m0a9AZyqwTIQCuOsuW9sEcz2o4FPzdJllYP5SZRexqiQJbb +cFZ7VkiHuKT3MOpd9vvQ6wBgiZP9DgtXqn1BHvs3qei7hhmDLKg4kpzN+6G2du9GPuXUHg9D cURbXiBz7eNfoA+d5YIoRH0w== X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi, =C2=A0=C2=A0=C2=A0 I'm after a little guidance around GLIBC/libc versioned= symbols, in particular using older symbol versions (2=2E2=2E5) and using '= artificially' unversioned symbols=2E A little background: I am a user of FPC/Lazarus, and use Lazarus to create= GUI applications to run on Linux desktop systems=2E When a GUI application= is compiled the resulting ELF binary ends up linked to a couple of dozen v= ersioned libc symbols, of particular interest to me are the six symbols: __= libc_start_main, dlopen, dlclose, dladdr, dlsym, and dlerror=2E These six s= ymbols are normally versioned as GLIBC_2=2E34 if the compile is carried out= on a recent Linux distro, and versioned as GLIBC_2=2E2=2E5 if compiled on = an older distro=2E This presents a problem - a binary created on a recent d= istro will not run on an older distro due to the symbol versioning=2E The g= enerally accepted workaround for this within the FPC/Lazarus community is t= o always keep an 'old' Linux VM handy for compiling on, however over time t= his is becoming a progressively more difficult solution=2E I've managed to achieve a simple workaround that allows the removing of ve= rsioning from symbols, as well as bringing in libdl=2Eso=2E2 as a 'NEEDED' = library=2E This yields a binary that runs on recent and older Linux distros= =2E I've also verified that for each of the above six symbols, both recent = (2=2E34) and older (2=2E2=2E5) versions point to the same entry point withi= n libc=2Eso=2E6=2E I'm left with two questions=2E=2E=2E (1) Is it OK to use unversioned libc symbols through 'manipulation' of the= compile-time linking process? This will result in the binary picking up th= e latest version of each symbol at run-time=2E I am not aware of unversione= d symbols normally being introduced into an application's Dynamic Symbol Ta= ble when a versioned one of the same name exists, and it seems that libc=2E= so=2E6 has contained NO unversioned symbols for at least 20 years=2E So it = is perhaps fair to say that at best unversioned libc symbols are not a 'nor= mal thing'=2E (2) Is it OK to instead hard-code (within the FPC RTL and Lazarus LCL) all= libc symbols to their earliest (in most cases GLIBC_2=2E2=2E5) versions? T= hen the only 'manipulation' required is injecting libdl=2Eso=2E2 as a 'NEED= ED' library=2E But will symbols versioned GLIBC_2=2E2=2E5 at some future ti= me be depreciated from GLIBC? And/or will libdl=2Eso=2E2 at some future tim= e be removed, thereby breaking any binary that has it as 'NEEDED'? Would much appreciate any help anyone can offer, cheers, rob=C2=A0=C2=A0 :-)