can i delete libtool / shared library support ?

Mike Frysinger vapier@gentoo.org
Mon Feb 7 09:27:16 GMT 2022


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/newlib/attachments/20220207/d7b649b4/attachment.sig>


More information about the Newlib mailing list