Re: Intel's new rte_memcpy()

[Luke Gorrie <luke at snabb dot co>]

On 10 March 2015 at 16:24, Mike Frysinger <vapier@gentoo.org> wrote:
> 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.

Thanks for that heads-up. I will keep it in mind.

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

I'd like to avoid this for my particular application. The idea is that
people will download the source, make extensions, then build a release
and distribute it to their friends. The users are networking people
rather than professional programmers and I want to keep the "build my
first application" experience simple. (I'm probably in a similar boat
to the people creating build-your-own-stand-alone-video-game toolkits,
a bit away from the Linux/GNU mainstream :-))

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

Thanks for the tip. I'll treat these issues as bugs and add tests for
them if they come up. For now I have only sanity-tested by running
"myapp --help" inside docker containers of various distros to make
sure that it links and starts. I hope that automating this some fine
day will be a sufficient test for catching dependencies like this that
sneak in.

Thanks again,
-Luke