This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: Building for older systems
- From: Michael Eager <eager at eagerm dot com>
- To: Ãngel GonzÃlez <keisial at gmail dot com>
- Cc: libc-help at sourceware dot org
- Date: Tue, 01 Dec 2015 07:03:20 -0800
- Subject: Re: Building for older systems
- Authentication-results: sourceware.org; auth=none
- References: <565B0993 dot 7040202 at eagerm dot com> <565BA0CA dot 4070102 at gmail dot com>
On 11/29/2015 05:05 PM, Ãngel GonzÃlez wrote:
On 29/11/15 15:20, Michael Eager wrote:
I'm trying to build packages (gcc, etc.) on a newer
version of Linux which can run on an older Linux system
with an older glibc. I've run into the memcpy versioning
problem._2.14
(...)
Any solutions to building for an older glibc?
If you just want to work around the memcpy 2.14 version bump, you can:
a) #define memcpy memmove
That is more or less equivalent to including a .symver for memcpy.
The problem is that this needs to be included in each of many thousands
of source files.
b) Use a memcpy wrapper that explicitely uses the old symbol, as
described in http://stackoverflow.com/a/8862631
This does work, I find strange your claim that ârequirements for
memcpy@GLIBC_2.14 are inherited from libc.soâ.
I haven't investigated where this is happening, but I am linking
object files which do not have dependencies on memcpy@GLIBC_2.14
and the resulting executable does. Possibly there is a dependency
in crti.o or crtn.o.
--
Michael Eager eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077