This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Intel's new rte_memcpy()
- From: Luke Gorrie <luke at snabb dot co>
- To: Luke Gorrie <luke at snabb dot co>, OndÅej BÃlka <neleai at seznam dot cz>, "H.J. Lu" <hjl dot tools at gmail dot com>, éå(åå) <ling dot ml at alibaba-inc dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 10 Mar 2015 07:50:22 +0100
- Subject: Re: Intel's new rte_memcpy()
- Authentication-results: sourceware.org; auth=none
- References: <CAA2XHbendDcfydewf2nrpPQkSsDWPdEH0SMsnqZAFsLF9q4Fzg at mail dot gmail dot com> <CAMe9rOpELuXQLvHQLLAeZitTTcz-xeg=ROoDm0dHe-fg4m-Jew at mail dot gmail dot com> <20150131184837 dot GA3539 at domone> <CAA2XHbcvDWjrshkdyo3++PnViOs5MdOC_+8qZoEb5UXJ21F1zA at mail dot gmail dot com> <20150305174741 dot GC6730 at vapier>
Hi Mike,
Thank you for taking the time to reply.
On 5 March 2015 at 18:47, Mike Frysinger <vapier@gentoo.org> wrote:
> On 02 Feb 2015 10:00, Luke Gorrie wrote:
>> I would like to create relatively portable binaries that don't depend
>> on recent glibc releases. For this purpose I am tempted to reference
>> an older memcpy in my symbol table with this trick:
>>
>> __asm__(".symver memcpy,memcpy@GLIBC_2.2.5");
>
> binding just one symbol to the old one wouldn't help with all the other symbols
> that have newer bindings.
>
> you'd also have to analyze the semantics between the old/new symbol to see
> whether you could safely bind it. memcpy is a bit of an uncommon case ...
> usually the breakage that causes a new symbol version includes an API change
> too.
>
> so in general, the only way to build a program that is safe to use with older
> glibcs is to actually get a toolchain using that older glibc and then build/link
> against it.
Currently I am using my application's test suite to inspect the final
binary with objdump and check on the GLIBC version requirement. The
application can compile on any platform but the test suite fails if
the final binary requires a version of libc beyond that our
documentation states.
Compiling on Ubuntu 14.04 the only symbol requiring GLIBC > 2.7 was
memcpy and so that is the only one that I have rebound.
Ideally I would like to use the latest memcpy available, since I don't
need the backwards compatible behavior, but if the cost of that is
depending on minimum GLIBC 2.14 then I don't think it's the right
choice for me in 2015.
I would love to hear about it if I have misunderstood some detail or
could accomplish binary portability in a simpler way. (I don't think
that requiring an old distro to build releases is better and that
would probably bite me if I need a recent GCC for some reason.)
Cheers,
-Luke