Re: can i delete libtool / shared library support ?

[Corinna Vinschen <vinschen@redhat.com>]

I was never involved in this part of the project, so I can't say
if there's any value in it.  Jeff?

On Feb  7 04:27, Mike Frysinger wrote:
> 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