This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Intel's new rte_memcpy()

Hi Mike,

Thank you for taking the time to reply.

On 5 March 2015 at 18:47, Mike Frysinger <> 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.)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]