From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-2.7 required=3.0 tests=AWL,BAYES_00, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF, FORGED_GMAIL_RCVD,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=no autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 7F1EF1F463 for ; Mon, 6 Jan 2020 22:43:22 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:from:to:references:cc:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=St/cyk9LBuSBx9AC foYTWBqTeduAr29EqH+SrVjSb5g5wQ9d3gT+9W0Eu+zCnKcdZA4alO29pLK2Zq03 9l1zO1Ja2mBjsvEIFWHlfHRMY6n4YCO83rsnHHGQxHRZ+ERAK7N5r96tfkknZWT+ db8BFeoARAUrbjeZlbxK/DvG0Gc= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:subject:from:to:references:cc:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; s=default; bh=wYIpMlUkQjtzWVjxs1sLsA 2LiUU=; b=VtYwnqZVZa9iXur+Il3e70fUqjsP/dmR8uAFt53aWtT9u8C0CkUaF1 GqrAaxa7uoO8+pKN12x6JKVpuVBhSigJh6s7dkyAgEffQ972ISHye45Na4o7aVEK ICX9ew95lxX0pIxq5o8OU9hX8KWFKIMqCgIGBZsRXwYx0Igt2J4lk= Received: (qmail 116919 invoked by alias); 6 Jan 2020 22:43:19 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 116909 invoked by uid 89); 6 Jan 2020 22:43:19 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mail-pg1-f193.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:references:cc:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=r1OpxdYXKobOPs/7Do/JNxlOzaZbJh0WU1ttK+rbhxA=; b=j0ptxwQ+7p2LHal5jZ/QzNdgpOeiZOgIlcSo3Waz7rdV+qvKcEDNVPitKRC0Sifw0h SHfFlufr5mL2xkZb4PhBIRlwS+qrm1o23ghi0lSPLtn748Tbbz7X3Icef0vR/Q5b24ih 8WgIpXs7HNr0QulewUqhivMmCc9HcagyN7b2b2SgofoA9UIB/1IFM6iIRTDk6QDEdbDd bFLHeoOuEEFwi1MObqeuDtl4SujYj0CwQAa0Rai3lCvRZPxkvl8aPWi7Cstcl2qrWbtX WgLcxMhaUqo0cbRtZ0RSvTNiwZMqRd3+Oo6HNAnVCtThykob8zmAEH/v30KRrVwOpHJb BnLw== Subject: Re: A question on glibc backwards compatibility From: Jason Yang To: Zack Weinberg References: <2e35fa4e-7b88-ddeb-ddd4-bb87d9ad9ebb@gmail.com> <61ae5450-a410-b438-9f7d-5dbd3bbc2838@gmail.com> Cc: libc-alpha@sourceware.org Message-ID: <480a2bab-b4ff-70a5-e688-31b51f16f42a@gmail.com> Date: Tue, 7 Jan 2020 07:43:13 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <61ae5450-a410-b438-9f7d-5dbd3bbc2838@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Dear Zack, Sorry I forgot to cc to libc-alpha. Thank you so much for this great explanation!!! I will follow your instruction and revise my code again. I have another question, when I tried to compile newer version of glibc on old kernel, glibc shows error message that the kernel is too old. I know that newer version of glibc may require newer kernel to provide newer features. But what if the programs do not call newer system calls functions inside glibc, which means if we disable kernel version check code inside newer glibc and make it able to compile and run on old kernel so that newer distros can run on old kernel.(Here, we have a case of creating a container(ubuntu 18.04) and make it able to run on old host(centos 5.5). As we all know, container on host uses host kernel and the glibc inside container is much newer than host version, requiring much newer version of kernel to make it able to run. ) Besides, thank you so much to share me the project fakeroot!! On 2020/01/07 4:59, Jason Yang wrote: > Dear Zack > > Thank you so much for the reply. > > I compile my dynamic library against glibc 2.5 on centos 5.5. > Therefore, the case should be compiling everything against old glibc > on old kernel. Then I use this library on ubuntu 18.04, where newer > glibc and new kernel are installed and running. I chose this way > because I expected to run my compiled dynamic library across different > distros(with different versions of glibc and kernels) and gain maximum > compatibility so that I just need to maintain only one copy of source > code. > > Unfortunately, my dynamic library involves a lot of re-implementation > of system calls functions in glibc, i.e, I use LD_PRELOAD tricks to > overwrite some system calls functions inside glibc such as open, > unlink, link, mkdir and etc. I added my own implementation before > calling the real glibc functions. > > When I compiled my dynamic library against newer glibc and newer > kernel, for example, I compiled everything on ubuntu 18.04, and run > this .so on ubuntu 18.04, the behavior acts as expected. On the other > case, if I compiled everything on centos 5.5 with old glibc(2.5) and > old kernel, then copy the .so and run it on ubuntu 18.04, some system > call functions do not act as expected. > > The issue may be caused by my implementation or maybe because of cross > distros(centos 5.5 vs ubuntu 18.04) compiling or may be caused by glibc? > > My imagination is that if glibc supports strict backwards > compatibility my library should work correctly on newer distros(with > newer glibc and newer kernel). > > > Regards > > Jason > > > On 2020/01/06 22:35, Zack Weinberg wrote: >> On Sun, Jan 5, 2020 at 9:59 PM Jason Yang >> wrote: >>> I knew that glibc has very good backwards compatibility. But I have an >>> issue during my development. I use very old glibc(version 2.5) to >>> compile my own developed dynamic library and use it on newer kernel, >>> some weird issues happen. >> Do you mean that you compile your dynamic library against glibc 2.5 on >> a computer running an equally old kernel, then you copy the dynamic >> library to a computer with a newer kernel and/or C library, and then >> you observe issues with the programs that use the library? >> >> Or, do you mean that you observe weird issues while trying to >> *compile* your dynamic library against the combination of glibc 2.5 >> and a newer kernel? >> >>> Here, I could not explain these issues in >>> details because there are so much code involved. >> Please try to explain what these weird issues are in more detail. >> Even if you can't completely explain it, every little bit will help us >> help you. >> >>> But my question is >>> that, glibc backwards compatibility is strict support? or if there are >>> any(few) exceptions? If there are exceptions where can I find them? >> If you compile a dynamic library against an old C library *and* an old >> kernel, and then move that library into a newer environment, it's >> definitely supposed to work.  I know of less than ten cases where it >> might not work, and all of them involve either a library even older >> than the one you're using (like, the original glibc 2.0) or functions >> that are so unsafe that it's a bug to use them at all (e.g. gets, >> encrypt). >> >> Compiling against an old C library coupled with a much newer kernel is >> also supposed to work, but I wouldn't be surprised if >> current-generation kernel headers had subtle incompatibilities with >> very old glibc headers. >> >> zw