1

I am working on developing a tool in the Linux Mint 17.2 environment that will be run primarily in CentOS 6.3. This tool is made up of several C programs called in succession by a python script.

Upon testing this build, an object was referencing GLIBC_2.14, which isn't available in CentOS 6.3. Using this post, I was able to find that the offending call was 'memcpy' referenced from GLIBC_2.14. After looking to see if there were any symbols in older versions of GLIBC that I could link against, I found that GLIBC_2.0 would work.

I then tried to link the call of memcpy with memcpy@GLIBC_2.0 using an asm call in the source code, as suggested in the above linked solution.

__asm__(".symver memcpy,memcpy@GLIBC_2.0");

However, when building this, I received an undefined reference to memcpy@GLIBC_2.0 .

I'm fairly new to this type of development. Is there something simple that I'm overlooking as to why this isn't working?

Community
  • 1
  • 1
LuckyBulldog
  • 11
  • 3
  • Don't build your tool on Linux Mint 17.2; build it on CentOS 6.3 instead? (Also realize that CentOS 6.3 is old, unsupported, and full of security flaws at this point.) – Etan Reisner Jul 29 '15 at 17:38
  • Valid point. Choice of environment isn't really my decision in this case, but your comment is probably the best idea. – LuckyBulldog Jul 29 '15 at 17:48
  • It should be possible (using directives like that and linker files) to control specifically enough what versions of the symbols you use but you are likely to spend much longer getting it to work then it'll take to install CentOS 6.3 from scratch. That being said a quick look at `libc.so.6` on a CentOS 6.6 system doesn't see that version of symbols. I see `GLIBC_2.2.5` as the oldest but I don't see a memcpy with that tag (or any tags for that matter). – Etan Reisner Jul 29 '15 at 17:56
  • You were right about `GLIBC_2.2.5`, that's the library to which I should be linking. It worked in one case. However, another binary is using `memcpy`, though it isn't called (by me). No matter if I use the linking method above, it doesn't correct the reference to `memcpy@GLIBC_2.14`. I'm stuck here once again. – LuckyBulldog Jul 31 '15 at 16:50
  • A binary you are building or one you are just packaging? – Etan Reisner Jul 31 '15 at 16:52
  • I'm building it myself. – LuckyBulldog Jul 31 '15 at 17:03
  • And the binary is including that symbol even though you don't use it? Does it come from a system-library you are linking against? Did you fix the linkage on every library/etc. you are building with that binary? – Etan Reisner Jul 31 '15 at 17:07

0 Answers0