Am 25.08.2015 um 19:17 schrieb Nicolas Thierry-Mieg <Nicolas.Thierry-Mieg at imag.fr>:> > On 08/25/2015 07:11 PM, Leon Fauster wrote: >> >> The support of this vendor (2) is willing to provide >> such OS support for there products. >> >> The same was also offered by a different vendor (1), they just recompiled >> there software and gave us the opportunity to test it under C6. Before that >> it only was running under Ubuntu. I just was curious about such solution >> to give the second vendor a hint (the symptoms are the same). > > So the easiest solution would be that the vendor (2) > build the software on a C6 system. Most likely it will > compile fine, and the produced binary will run on C6 as > well as more recent distributions.sure, thats always possible but exist there some backward compatibility switch when compiling against a newer glibc? -- LF
On 08/25/2015 05:48 PM, Leon Fauster wrote:> Am 25.08.2015 um 19:17 schrieb Nicolas Thierry-Mieg <Nicolas.Thierry-Mieg at imag.fr>: >> >> On 08/25/2015 07:11 PM, Leon Fauster wrote: >>> >>> The support of this vendor (2) is willing to provide >>> such OS support for there products. >>> >>> The same was also offered by a different vendor (1), they just recompiled >>> there software and gave us the opportunity to test it under C6. Before that >>> it only was running under Ubuntu. I just was curious about such solution >>> to give the second vendor a hint (the symptoms are the same). >> >> So the easiest solution would be that the vendor (2) >> build the software on a C6 system. Most likely it will >> compile fine, and the produced binary will run on C6 as >> well as more recent distributions. > > > sure, thats always possible but exist there some backward > compatibility switch when compiling against a newer glibc? >No, not really. When you compile a program it LINKS against the standard c or c++ library. You have to run it on a c library that has all the features / functions .. that is WHY it puts the version in. If you want it to work on CentOS, it needs to be compiled on CentOS .. pretty simple. There does EXIST a compat-glibc (or compat-gcc) to run OLDER stuff (ie things for CentOS-6) on a newer distro (ie CentOS-7). But those side load an older version of the libraries for use on the new system. Technically, if they used the older version of glibc/gcc (and any other required library links) on ubuntu, you can make things work, but it would be easier to compile the software on the platform where it is intended to work. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos/attachments/20150825/18f1163f/attachment-0001.sig>
Am 26.08.2015 um 01:04 schrieb Johnny Hughes <johnny at centos.org>:> On 08/25/2015 05:48 PM, Leon Fauster wrote: >> Am 25.08.2015 um 19:17 schrieb Nicolas Thierry-Mieg <Nicolas.Thierry-Mieg at imag.fr>: >>> >>> On 08/25/2015 07:11 PM, Leon Fauster wrote: >>> >>> So the easiest solution would be that the vendor (2) >>> build the software on a C6 system. Most likely it will >>> compile fine, and the produced binary will run on C6 as >>> well as more recent distributions. >> >> >> sure, thats always possible but exist there some backward >> compatibility switch when compiling against a newer glibc? >> > > No, not really. When you compile a program it LINKS against the > standard c or c++ library. You have to run it on a c library that has > all the features / functions .. that is WHY it puts the version in. > > If you want it to work on CentOS, it needs to be compiled on CentOS .. > pretty simple. > > There does EXIST a compat-glibc (or compat-gcc) to run OLDER stuff (ie > things for CentOS-6) on a newer distro (ie CentOS-7). But those side > load an older version of the libraries for use on the new system. > > Technically, if they used the older version of glibc/gcc (and any other > required library links) on ubuntu, you can make things work, but it > would be easier to compile the software on the platform where it is > intended to work.yep, thats the so called backward compatibility https://www.kernel.org/pub/software/libs/glibc/hjl/compat/ okay, thanks for the input. I will try to convince the vendor. -- LF
On 8/25/2015 3:48 PM, Leon Fauster wrote:> sure, thats always possible but exist there some backward > compatibility switch when compiling against a newer glibc?binary compatibility has /never/ been a goal of the linux/gpl architects/authors. in fact, it seems like they make design decisions to discourage it. Red Hat, OTOH, goes to great lengths to try and implement it within a major release, but they are fighting upstream to do so. -- john r pierce, recycling bits in santa cruz
On 08/25/2015 04:22 PM, John R Pierce wrote:> binary compatibility has /never/ been a goal of the linux/gpl > architects/authors. in fact, it seems like they make design decisions > to discourage it.I don't think that's true. Development in GNU/Linux is highly de-centralized, and some projects are better at stability than others. Linux has maintained an extremely stable interface for user-space applications. glibc uses versioned symbols for backward compatibility. The original question was about forward-compatibility, which is a much harder problem. Not all developers do as good a job with backward compatibility, but that problem is considerably more pronounced in the high level languages, where versioned libraries just aren't a thing. And that's why you see docker and other containers gaining traction, so that applications can be run in an environment with specific library versions.