<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Jul 8, 2017 at 3:37 PM, Geoffrey Thomas <span dir="ltr"><<a href="mailto:geofft@ldpreload.com" target="_blank">geofft@ldpreload.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">In the general case, does this actually change the API/ABI that your application uses, or does it just change the ABI that your application _claims_ to expect? That is, does your memcpy.c emit code that actually intends to call memcpy@GLIBC_2.2.5, or does it emit code that intends to call memcpy@@GLIBC_2.14 but lies about it because of .symver?<br></blockquote><div><br></div><div>Looking at the resulting libraries with `nm`, it actually emits code that calls <span style="font-size:12.8px">memcpy@GLIBC_2.2.5, to the best of my understanding.</span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
In the particular case of memcpy, I think this is fine because the ABI change from 2.2.5 to 2.14 is forwards-compatible, if I'm reading the manpage and glibc commit 0354e355 right. glibc used to have a memcpy that was safe to call with overlapping regions; the spec says memcpy requires the regions not to overlap, and you should use memmove if they overlap. In glibc 2.13, they optimized it assuming the regions didn't overlap, which broke older programs. So in glibc 2.14, they aliased memcpy@GLIBC_2.2.5 to memmove, and added the symbol version GLIBC_2.14 to the new, optimized memcpy.</blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
For an application calling memcpy correctly, I think this means _either_ memcpy@GLIBC_2.2.5 or memcpy@@GLIBC_2.14 is fine to call, and if you have the option of either, memcpy@@GLIBC_2.14 is going to be faster (which is why newer toolchains default to it), but the two have the same calling convention and everything.<br>
<br>
This means that, if the only incompatibility is just memcpy, this approach should work -- but also you can probably define a weak symbol named memcpy@@GLIBC_2.14 that just relocates to memcpy@GLIBC_2.2.5 (and perhaps auditwheel can stuff this symbol into your ELF objects, without needing to change the compilation process). If the final system's libc provides memcpy@@GLIBC_2.14, then you'll still get the faster version.<br></blockquote><div><br></div><div><span style="font-size:12.8px">I'm not sure exactly how to do this, but it sounds like it would be a neat trick as well.</span><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Is this the only incompatible symbol worth worrying about? If there are others that actually changed ABI in a backwards-incompatible way (that is, you can't call a program compiled with the new symbol against the old symbol, and glibc provides two disjoint versioned implementations) then I suspect this is unsafe.</blockquote><div><br></div><div>I'm not sure exactly how general of a solution it is. But if you have a wheel that really won't work if it uses the old glibc symbols, then it's not as if compiling it on the manylinux1 centos 5 docker image will help either.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Geoffrey Thomas<br>
<a href="https://ldpreload.com" rel="noreferrer" target="_blank">https://ldpreload.com</a><br>
<a href="mailto:geofft@ldpreload.com" target="_blank">geofft@ldpreload.com</a></font></span><div class="gmail-HOEnZb"><div class="gmail-h5"><br>
<br>
On Fri, 7 Jul 2017, Robert T. McGibbon wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Hey all,<br>
I think I may have figured out a new way to build manylinux1 on non-CentOS 5 machines with newer toolchains, at least in relatively<br>
simple cases. The thing that prevents most libraries from being manylinux1-compatible is that they link against too-recent versioned<br>
symbols in glibc. This suggests, then, that we might be able to fix the problem during compilation by forcing the linker to link the<br>
libraries against older (manylinux1 compatible) symbols. It seems like there are some assembly + linker tricks (also this) that work to<br>
force just that.<br>
<br>
In order to test this out, I took a look at the symbols that were causing manylinux1 incompatibility in a project of mine when compiled<br>
on CentOS 7. In this case, it was just memcpy@@GLIBC_2.14.<br>
<br>
So, I dropped this file into my project:<br>
```<br>
$ cat memcpy.c<br>
#include <string.h><br>
<br>
asm (".symver memcpy, memcpy@GLIBC_2.2.5");<br>
void *__wrap_memcpy(void *dest, const void *src, size_t n) {<br>
return memcpy(dest, src, n);<br>
}<br>
```<br>
<br>
And then modified my setup.py to<br>
<br>
````<br>
+def manylinux1(extensions):<br>
+ for ext in extensions:<br>
+ ext.sources.append('memcpy.c'<wbr>)<br>
+ ext.extra_link_args.append('-<wbr>Wl,--wrap=memcpy')<br>
+ return extensions<br>
+<br>
<br>
setup(name='project_name<br>
author='Robert McGibbon',<br>
author_email='<a href="mailto:rmcgibbo@gmail.com" target="_blank">rmcgibbo@gmail.<wbr>com</a>',',<br>
- ext_modules=extensions,<br>
+ ext_modules=manylinux1(extens<wbr>ions),<br>
```<br>
<br>
<br>
Lo and behold, it actually works! Obviously one would have to wrap more symbols for other projects that make heavier use of glibc and<br>
there's nothing that this can do about the fact for wheels that link against external, precompiled libraries that auditwheel grafts into<br>
the manylinux wheel, since it requires changes to the compile, but it's still cool.<br>
<br>
Has anyone tried this kind of thing before?<br>
<br>
--<br>
-Robert<br>
<br>
</blockquote>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div>-Robert</div></div></div>
</div></div>