Well, as I said, I was mistaken and the .symver directive does actually
work for this, but the point of forcing the version is to provide a
backwards compatible binary. If I compile with GCC on a modern system, it
might generate a call to memcpy@GLIBC_2.14, so then that binary won't run
on a system
Tom Mason writes:
> Is there any way for me to force the version for these symbols aswell?
It seems pointless because the ABI for these symbols will never change.
-Andi
Actually, never mind, it's working fine:
https://gist.github.com/wheybags/b7e4152daf76c72503e9e1f52f3dca3d and I
have some other problem.
On Fri, Jan 26, 2018 at 9:22 PM, H.J. Lu wrote:
> On Fri, Jan 26, 2018 at 1:17 PM, Tom Mason wrote:
> > I'm not entirely sure I understand that issue. From
On Fri, Jan 26, 2018 at 1:17 PM, Tom Mason wrote:
> I'm not entirely sure I understand that issue. From what I understand, calls
> to a function in a shared library should always use the PLT?
> Also, I don't understand the purpose of applying hidden visibility to an
> extern symbol,
There is no n
I'm not entirely sure I understand that issue. From what I understand,
calls to a function in a shared library should always use the PLT?
Also, I don't understand the purpose of applying hidden visibility to an
extern symbol,
But anyway, doesn't matter terribly much if I understand :p
On Fri, Jan
On Fri, Jan 26, 2018 at 12:29 PM, Tom Mason wrote:
> Hi,
> I've got a project here: https://github.com/wheybags/glibc_version_header
> which uses .symver directives to link to a specified version of glibc, so
> long as it's older than the version on your system.
> This works, but a problem I'm hav
