[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.

--
Peter Keller                             Tel.: +44 (0)1223 353033
Global Phasing Ltd.,                     Fax.: +44 (0)1223 366889
Sheraton House,
Castle Park,
Cambridge CB3 0AX
United Kingdom


Reply to: