Hi --
I'm trying to build an application on CentOS 7 which can run on older versions of CentOS. I'm running into problems with versioning of memcpy in Glibc. Executables built on CentOS 7 require memcpy from glibc-2.14, which causes the program not to load on systems with older versions of glibc.
My online search suggests to add an asm() with a .symver option to select memcpy from glibc-2.2.5 in each of the source files which reference memcpy(). This isn't practical with a program with tens of thousands of source files.
Does anyone have a reasonable solution?
Once upon a time, Michael Eager eager@eagerm.com said:
I'm trying to build an application on CentOS 7 which can run on older versions of CentOS. I'm running into problems with versioning of memcpy in Glibc. Executables built on CentOS 7 require memcpy from glibc-2.14, which causes the program not to load on systems with older versions of glibc.
Most shared libraries are "upwards compatible" but not "backwards compatible" - builds against an old version will run with the new version, but not the other way around. You've found this with glibc, but you could also run into it with other libraries.
My online search suggests to add an asm() with a .symver option to select memcpy from glibc-2.2.5 in each of the source files which reference memcpy(). This isn't practical with a program with tens of thousands of source files.
Does anyone have a reasonable solution?
Would it be practical to use mock and build on the oldest version you want to support? This is how EPEL packages are built for example. It is targeted at building RPMs, but you can manually use copy-in and copy-out to do other things.
On 11/23/2015 07:43 AM, Chris Adams wrote:
Once upon a time, Michael Eager eager@eagerm.com said:
I'm trying to build an application on CentOS 7 which can run on older versions of CentOS. I'm running into problems with versioning of memcpy in Glibc. Executables built on CentOS 7 require memcpy from glibc-2.14, which causes the program not to load on systems with older versions of glibc.
Most shared libraries are "upwards compatible" but not "backwards compatible" - builds against an old version will run with the new version, but not the other way around. You've found this with glibc, but you could also run into it with other libraries.
The situation with memcpy is a bit different. This isn't really a forward/backward interface compatibility issue.
There was a patch applied to memcpy to improve performance on some architectures, but it also changed the order in which data was moved. Some programs were dependent on this and they broke with the new implementation. These programs did not conform to the non-overlapping data requirements in memcpy's specification. Programs which did conform worked with both the new and old implementation.
To prevent non-conforming programs from using the new version of memcpy, they tagged it with glibc-2.14. Unfortunately, this also makes conforming programs, which work with either the old or new implementation from running on systems which have older versions of glibc.
My online search suggests to add an asm() with a .symver option to select memcpy from glibc-2.2.5 in each of the source files which reference memcpy(). This isn't practical with a program with tens of thousands of source files.
Does anyone have a reasonable solution?
Would it be practical to use mock and build on the oldest version you want to support? This is how EPEL packages are built for example. It is targeted at building RPMs, but you can manually use copy-in and copy-out to do other things.
I'll look into mock.
On 11/23/2015 07:33 AM, Michael Eager wrote:
Does anyone have a reasonable solution?
I'd start here: https://wiki.linuxfoundation.org/en/Using_lsbdev
On 11/23/2015 07:57 AM, Gordon Messmer wrote:
On 11/23/2015 07:33 AM, Michael Eager wrote:
Does anyone have a reasonable solution?
I'd start here: https://wiki.linuxfoundation.org/en/Using_lsbdev
Yeah. I know about LSB and I've worked with the LSB committee. Maybe it's time I tried using it. :-)
It does seem to be a sledge hammer to address what seems to be a minor issue.
On 11/23/2015 04:33 PM, Michael Eager wrote:
Hi --
I'm trying to build an application on CentOS 7 which can run on older versions of CentOS. I'm running into problems with versioning of memcpy in Glibc. Executables built on CentOS 7 require memcpy from glibc-2.14, which causes the program not to load on systems with older versions of glibc.
My online search suggests to add an asm() with a .symver option to select memcpy from glibc-2.2.5 in each of the source files which reference memcpy(). This isn't practical with a program with tens of thousands of source files.
Does anyone have a reasonable solution?
IMO you should really be building your app on an older Centos version (5 or 6). Then your binary should run everywhere, though it may sometimes require installing a -compat package.
An alternative is to link everything statically. Not as good a solution, as it introduces security concerns.
On 11/23/2015 08:06 AM, Nicolas Thierry-Mieg wrote:
On 11/23/2015 04:33 PM, Michael Eager wrote:
Hi --
I'm trying to build an application on CentOS 7 which can run on older versions of CentOS. I'm running into problems with versioning of memcpy in Glibc. Executables built on CentOS 7 require memcpy from glibc-2.14, which causes the program not to load on systems with older versions of glibc.
My online search suggests to add an asm() with a .symver option to select memcpy from glibc-2.2.5 in each of the source files which reference memcpy(). This isn't practical with a program with tens of thousands of source files.
Does anyone have a reasonable solution?
IMO you should really be building your app on an older Centos version (5 or 6). Then your binary should run everywhere, though it may sometimes require installing a -compat package.
That causes a number of other problems, when the only issue is accessing a working version of memcpy from the installed glibc.
On 11/23/2015 06:00 PM, Michael Eager wrote:
On 11/23/2015 08:06 AM, Nicolas Thierry-Mieg wrote:
On 11/23/2015 04:33 PM, Michael Eager wrote:
Hi --
I'm trying to build an application on CentOS 7 which can run on older versions of CentOS. I'm running into problems with versioning of memcpy in Glibc. Executables built on CentOS 7 require memcpy from glibc-2.14, which causes the program not to load on systems with older versions of glibc.
My online search suggests to add an asm() with a .symver option to select memcpy from glibc-2.2.5 in each of the source files which reference memcpy(). This isn't practical with a program with tens of thousands of source files.
Does anyone have a reasonable solution?
IMO you should really be building your app on an older Centos version (5 or 6). Then your binary should run everywhere, though it may sometimes require installing a -compat package.
That causes a number of other problems,
can you please provide some details? I'm genuinely curious as I've been faced with this occasionally and the only problem I've encountered is having to install a few *-compat packages. thanks.
when the only issue is accessing a working version of memcpy from the installed glibc.
On 11/23/2015 09:10 AM, Nicolas Thierry-Mieg wrote:
On 11/23/2015 06:00 PM, Michael Eager wrote:
On 11/23/2015 08:06 AM, Nicolas Thierry-Mieg wrote:
On 11/23/2015 04:33 PM, Michael Eager wrote:
Hi --
I'm trying to build an application on CentOS 7 which can run on older versions of CentOS. I'm running into problems with versioning of memcpy in Glibc. Executables built on CentOS 7 require memcpy from glibc-2.14, which causes the program not to load on systems with older versions of glibc.
My online search suggests to add an asm() with a .symver option to select memcpy from glibc-2.2.5 in each of the source files which reference memcpy(). This isn't practical with a program with tens of thousands of source files.
Does anyone have a reasonable solution?
IMO you should really be building your app on an older Centos version (5 or 6). Then your binary should run everywhere, though it may sometimes require installing a -compat package.
That causes a number of other problems,
can you please provide some details? I'm genuinely curious as I've been faced with this occasionally and the only problem I've encountered is having to install a few *-compat packages. thanks.
Building on an older version of CentOS means using older compilers and libraries. Some applications require building with more current tools.
So you end up between a rock and a hard place. You can try to build on the older system for library compatibility, but then you have to use development tools from newer versions. Or you can build with the newer tools, and you have compatibility issues running on the older system.
Once upon a time, Michael Eager eager@eagerm.com said:
Building on an older version of CentOS means using older compilers and libraries. Some applications require building with more current tools.
Maybe try an older base OS but with tools from a software collection add-on? That's trickier to do with mock (I figured it out once but don't remember now).
-
Chris Adams -
Gordon Messmer -
Michael Eager -
Nicolas Thierry-Mieg