Re: can i delete libtool / shared library support ?

It was initially requested and implemented by a newlib user.  I have seen
some requests for x86_64 support, but it hasn't
been updated in a while.  We can delete it and point any user to a previous
branch if they want to resurrect it.

-- Jeff J.

On Mon, Feb 7, 2022 at 6:48 AM Corinna Vinschen <[email protected]> wrote:

> 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
>
>
>