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? -- Michael Eager eager at eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
Once upon a time, Michael Eager <eager at 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. -- Chris Adams <linux at cmadams.net>
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 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 07:43 AM, Chris Adams wrote:> Once upon a time, Michael Eager <eager at 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. -- Michael Eager eager at eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
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. -- Michael Eager eager at eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
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_lsbdevYeah. 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. -- Michael Eager eager at eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077