Re: A question on glibc backwards compatibility

[Jason Yang <jasonyangshadow@gmail.com>]

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 <jasonyangshadow@gmail.com> 
>> 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