From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id ED43C3857806 for ; Tue, 18 Jul 2023 08:00:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org ED43C3857806 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1689667216; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=uRDL03qOGYim4vfIsghOZDIVGM+uP/2CAaCd4MSlDEY=; b=CdC6gMRef2RuSeGUNbO23GJCwrwsx4G8vzD31uChJ9kDeXrFzPzraWF7VCXKg1WM5NHM6R 6kbZi17mMPQv7/FlzRQsQQTMFO3lh4cRS81PClKZ5Fe5zVPzRXY4M9E0rkPhO/t+Zt6Vxh oHjAjHD8nfWxBYf4uMa3taPvEosiGmc= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-407-C3QCccQWPDiuon1Hy4UOEg-1; Tue, 18 Jul 2023 04:00:15 -0400 X-MC-Unique: C3QCccQWPDiuon1Hy4UOEg-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id E9613835050; Tue, 18 Jul 2023 08:00:04 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.2.16.6]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5384B2166B27; Tue, 18 Jul 2023 08:00:04 +0000 (UTC) From: Florian Weimer To: robert rozee via Libc-alpha Cc: robert rozee Subject: Re: question of compatibility between different GLIBC symbol versions References: Date: Tue, 18 Jul 2023 10:00:02 +0200 In-Reply-To: (robert rozee via Libc-alpha's message of "Tue, 18 Jul 2023 01:13:38 +0200") Message-ID: <87a5vtir99.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,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: * robert rozee via Libc-alpha: > A little background: I am a user of FPC/Lazarus, and use Lazarus to > create GUI applications to run on Linux desktop systems. When a GUI > application is compiled the resulting ELF binary ends up linked to a > couple of dozen versioned libc symbols, of particular interest to me > are the six symbols: __libc_start_main, dlopen, dlclose, dladdr, > dlsym, and dlerror. These six symbols are normally versioned as > GLIBC_2.34 if the compile is carried out on a recent Linux distro, and > versioned as GLIBC_2.2.5 if compiled on an older distro. This presents > a problem - a binary created on a recent distro will not run on an > older distro due to the symbol versioning. The generally accepted > workaround for this within the FPC/Lazarus community is to always keep > an 'old' Linux VM handy for compiling on, however over time this is > becoming a progressively more difficult solution. Starting with glibc 2.34, the statically linked startup code that calls __libc_start_main is incompatible with earlier glibc versions. So you'd have to bundle your own version of that. Removing symbol versioning as a whole is probably not a good idea. It will likely continue to work for a while in the sense that newly linked binaries will run correctly even if they combine FPC code with code written in other languages. (I expect that linked applications will keep working indefinitely as far as glibc is concerned.) Still it's probably better to use the .symver assembler directive to specify the symbol versions you want explicitly. (If you have your own assembler, you might have to implement it there first.) > (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 the latest version of each symbol at run-time. At run time, it really should be the earliest implemented (base) version, otherwise we have a bug. At static link time, the link editor picks the default symbol version, which is usually the most recent symbol version. > I am not aware of unversioned symbols normally being introduced into > an application's Dynamic Symbol Table when a versioned one of the same > name exists, and it seems that libc.so.6 has contained NO unversioned > symbols for at least 20 years. So it is perhaps fair to say that at > best unversioned libc symbols are not a 'normal thing'. It's usually the result of buggy underlinking, not something done deliberately. There seem to be other bugs as well. For example, on my system /usr/lib64/firefox/libipcclientcerts.so, has unversioned references to mprotect and sysconf: 52: 0000000000000000 0 FUNC GLOBAL DEFAULT UNDEF mprotect 53: 0000000000000000 0 FUNC GLOBAL DEFAULT UNDEF sysconf Even though it contains other versioned glibc symbols. It's also odd that these symbols come after the defined symbols in the table; with GNU_HASH, they should come before. This is probably a toolchain bug somewhere. > (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.2.5) > versions? Then the only 'manipulation' required is injecting > libdl.so.2 as a 'NEEDED' library. But will symbols versioned > GLIBC_2.2.5 at some future time be depreciated from GLIBC? No, these symbols will be provided indefinitely, as long as we maintained the current x86-64 ABI. > And/or will libdl.so.2 at some future time be removed, thereby > breaking any binary that has it as 'NEEDED'? The file may vanish from disk, but libdl.so.2 DT_NEEDED references will continue to work for as long as we maintain ABI compatibility.