From 8b3b0453a6e08f55bf02817a22dcbe228fde5d16 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ciro=20Santilli=20=E5=85=AD=E5=9B=9B=E4=BA=8B=E4=BB=B6=20?= =?UTF-8?q?=E6=B3=95=E8=BD=AE=E5=8A=9F?= Date: Thu, 28 Feb 2019 00:00:00 +0000 Subject: [PATCH] glibc: mention ABI stability --- README.adoc | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/README.adoc b/README.adoc index 62d51ba..5bfd71b 100644 --- a/README.adoc +++ b/README.adoc @@ -355,6 +355,11 @@ We can also test our hacked glibc on <> with: I just noticed that this is actually a good way to develop glibc for other archs. +In this example, we got away without recompiling the userland program because we made a change that did not affect the glibc ABI. TODO: find the best list of ABI stability rules available: + +* https://plan99.net/~mike/writing-shared-libraries.html +* https://stackoverflow.com/questions/2171177/what-is-an-application-binary-interface-abi + Note that for arch agnostic features that don't rely on bleeding kernel changes that you host doesn't yet have, you can develop glibc natively as explained at: * https://stackoverflow.com/questions/10412684/how-to-compile-my-own-glibc-c-standard-library-from-source-and-use-it/52454710#52454710