Re: Using time() leads to binary incompatibility of static executables

Dear Niels,

Thanks for responding.

On 20/08/17 06:41, Niels Thykier wrote:
> Peter Keller:
>> Dear all,
>>
> 
> Hi Peter,
> 
> Thanks for your interest and for testing the issue.
> 
>> We have come across a binary compatibility problem involving
>> Debian-testing: an executable built from the trivial test program at
>> the end of this message segfaults on Debian-testing in the call to the
>> time() function, when the executable was built on a CentOS 6 or CentOS
>> 5 system. We have tested this (both compiling and running) on a
>> variety of other distributions, and we have found that the following
>> conditions must all be satisfied to trigger the segfault:
>>
>>   * compilation/linking (with 'gcc -g --static test_time.c'):
>>     - on CentOS 5 or CentOS 6
>>     - the executable must be static
>>     - the executable must be 64-bit
>>   * running
>>     - must be run on Debian-testing (kernel 4.11)
>>
> 
> We very recently got a kernel 4.12.2 in Debian testing:
> 
>   * Could you test if that fixes the problem?
> 
>   * FYI, there was a glibc migration today.  So both has been updated
>     recently.

OK, after doing:

apt-get update
apt-get install linux-image-4.12.0
apt-get upgrade

and rebooting into the new kernel, the problem persists. On the system I 
set up for testing this, 'uname -a' now gives:

Linux deb-testing 4.12.0-1-amd64 #1 SMP Debian 4.12.6-1 (2017-08-12)
x86_64 GNU/Linux

> If not, let us move on to filing an actual bug.

OK - thanks.

> 
>> [...]
>>
>> We would be grateful for any comments from someone with more expertise
>> than us in this area. In particular:
>>
>>    * have we found a bug in Debian-testing, or is binary compatibility
>>      not to be expected under these circumstances?
>>
> 
> I suspect you have found a bug, but I am not entirely sure.  At first
> glance, I believe it should work/be compatible.  However, I would prefer
> to let people, who understand the technical aspect of the problem,
> answer this part if it has not been fixed by the recent changes. :)
> 
>>    * if it is a bug, which package should we report it under? (glibc?
>>      linux? some other package?)
>>
> 
> Good question.  When you tested in debian testing with linux 4.9 and
> linux 4.11, was the only different the kernel?  If so, I would go for
> the linux kernel.

Well, this problem came to our attention when a user of our software 
reported problems. He told us that our software worked or failed on 
almost identical systems that differed only in the running kernel (4.9 
and 4.11). We then narrowed it down to the time() function.

Unfortunately, our Debian guru is on holiday and I am more familiar with 
other distros. I haven't been able to work out a way of installing 
kernel 4.9 into Debian-testing that I am happy with, so I haven't tested 
this myself. Is it OK to put something like the following in 
/etc/apt/sources.list:

   deb http://ftp.uk.debian.org/debian/ stable main

and do 'apt-get install linux-image-4.9.0', or would that cause other 
problems?

Sorry for the long-winded answer, but it looks at the moment that it 
does depend on the kernel.

> If you want/need to retest it, please remember that we have the
> snapshot.debian.org service, which can provide you with versions of the
> archive as they looked on a given day.

Thanks, I'll bear that in mind.

> 
>>    * have upcoming changes in unstable or experimental already
>>      addressed this issue?
>>
> 
> Not that I know of, but I have not tried. To be honest, I think you
> might be a better judge of that if you are willing to test unstable. :)
> 
> Anyway, if the recent updates have not fixed the issue, please let us
> look into filing a bug. :)
> 
> Hope it was helpful. :)

Yes, very, many thanks. What are the next steps towards filing this a 
bug? With a hint about the proper way to install kernel 4.9 into 
Debian-testing, I could easily check with that kernel version first.

Regards,
Peter.