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

On 10 March 2015 at 16:24, Mike Frysinger <> 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 &
> and you are tying yourself to that version when you link against
> them.  depending on the target, 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,

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