Re: Intel's new rte_memcpy()

[Mike Frysinger <vapier at gentoo dot org>]

On 10 Mar 2015 07:50, Luke Gorrie wrote:
> 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.

just to be clear, the ABI change for memcpy was unrelated to the function
signature.  if you do hit a function that has a newer glibc symbol, it's
usually because the function signature changed, and using the .symver
redirect hack won't help you there.

> 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.)

getting an older distro is one way, but that's not what i said ... you can build 
a sep toolchain that uses an older glibc & gcc on a newer distro.

you should also note that gcc itself has symbol versioning with libgcc_s.so & 
libstdc++.so and you are tying yourself to that version when you link against 
them.  depending on the target, libgcc_s.so might be pulled in implicitly.
-mike

Attachment: signature.asc
Description: Digital signature