can i delete libtool / shared library support ?
Mike Frysinger <[email protected]>
| Newsgroups | gmane.comp.lib.newlib |
|---|---|
| Message-ID | <YgDl9AhBMitaTYBd@vapier> |
let's talk about the shared library support in newlib. i want to delete it. it was added in 2001. the commit doesn't have any info itself, and i can't find it in the mailing list archives to try and explain "why". https://sourceware.org/git/?p=newlib-cygwin.git;a=commit;h=2e1a71756e754ada402efe9f5e2d6378dc11e496 the README has a section on it, but only explains "how", not "why". and that leads me to a large limitation in the code: it only works when built for a target that already uses glibc, and only 32-bit x86. i.e. it will produce a shared libc.so & libm.so, but it doesn't provide its own ld.so, and it will still be loaded & run in an environment that otherwise is assuming glibc is used. e.g. when you configure gcc, you tell it you're targeting glibc, and it bakes assumptions about certain functions & behaviors into it as a result. i'll note that the configure.host logic is weird in its tuple selection. it requires the "vendor" field be set to "pc" even though it's meaningless, and it seems to accept any C library (i?86-pc-linux-*), but in reality, it only works with glibc (i.e. *-gnu). back in 2016, Jeff noted that he didn't think anyone used it, and that even then the code had rotted into a state that made it unusable (i.e. does not compile let alone link). this is because it mixes glibc headers with newlib headers, and that glibc had made incompatible changes to its internals. and that newlib depends on those internal behaviors. https://sourceware.org/legacy-ml/newlib/2016/msg01106.html i've taken a 32-bit x86 system and tried to compile newlib, and indeed it blows up pretty immediately when it starts to mix newlib & glibc headers. i'm fairly certain that getting it working again won't be that easy since the current newlib imported code is based on linuxthreads which was removed from glibc 2.4 which was released in 2006, and had already been deprecated for a while by that point. the replacement, NPTL, is drastically different. in my autotools build cleanup, keeping this libtool logic has been kind of a pita to try and make sure i don't break it. but on the otherhand, it's been broken for at least 5 years (and most likely even longer), no one is using it, and it's impossible for me to test. if no one is using it, and no one seems to be asking for it, and actually getting it working again will take a huge amount of effort, can i just delete all the complicated logic and be done ? if someone shows up years from now and wants to get it working, i don't think it will be that much harder. -mike
signature.asc
(application/pgp-signature, 833 B)
-----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEuQK1JxMl+JKsJRrUQWM7n+g39YEFAmIA5fQACgkQQWM7n+g3 9YE+GhAAtFkQLOV42warRRuLNRZ/4LWrFeEkMhfx9dgjdq3TFal+A+BqGtwry9aA uf3vuMfMa4t4H7PYBAKBLEy60JEnds4pBi4+SEToEyw8Adzyim7348dKyCSY9YFQ rgAbDxsjrxxS3Uc7DJvGEFajUzBjgLS/loWrAqhISOD6cqDRsTJyRdbbJ94O4dTD Zj7Px5RslqozELXFtPRhZxLyUHswoHZCr4jr/9G2355PLfZOXiDt6bsnC3KyC9J5 /Jns67eg7iI5LWHXkHhDv0+QWn3bQ+sfsXgqHmIG/N9R/QwxpyiSPQMqd/WXpnOr MsF91O2hgx+nQpLzDC1adIzSdakoBnXQFU95MHQNiKDHOMbaziBu3LhwIe+19uzE rIrai0GD7SYpmkSR8t70hIRjuqvyapkw64u9nhzc5NMTJgsBDh2RpdW27ySZzRuH iG2regWPRYUIddnV8zyat6tz1BF1wTB/ugCkgquT1QT+DlYoBIdHD//0y6Rwr+CF cjt0HrlkLQpfuxETII/xIyjG0mUHCnesunTXqJlhZRmSysMZw3/adHR5IMb5yLj7 4O2DCASgyjSMKpJitHPEc8amEpNYJGrDa/iZkpvYr15mdCjBrzBAXGXaQShssLS7 oTsqmfJ5r/4H1Bzbh386vkTKYIkOxMAwBoS5+U6LS0KRL+9kLX0= =rM/w -----END PGP SIGNATURE-----