From 65d53b9297b402f310f8d3019e71710d47af5895 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: Sun, 3 Mar 2019 00:00:00 +0000 Subject: [PATCH] glibc api stability: move to SO answer --- README.adoc | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/README.adoc b/README.adoc index 5bfd71b..67bdfda 100644 --- a/README.adoc +++ b/README.adoc @@ -355,10 +355,7 @@ 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 +In this example, we got away without recompiling the userland program because we made a change that did not affect the glibc ABI, see this answer for an introduction to ABI stability: https://stackoverflow.com/questions/2171177/what-is-an-application-binary-interface-abi/54967743#54967743 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: