From: Jeff Johnston <jjohnstn@redhat.com>
To: Newlib <newlib@sourceware.org>, Jeff Johnston <jjohnstn@redhat.com>
Subject: Re: can i delete libtool / shared library support ?
Date: Mon, 7 Feb 2022 14:30:46 -0500 [thread overview]
Message-ID: <CAOox84uJ6qchKGWxY2A1hzByXUSX+Ym_FLgyo8cWrnmDapSu=Q@mail.gmail.com> (raw)
In-Reply-To: <YgEG+85nSPUF4meB@calimero.vinschen.de>
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 <vinschen@redhat.com> 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
>
>
>
next prev parent reply other threads:[~2022-02-07 19:31 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-07 9:27 Mike Frysinger
2022-02-07 10:30 ` Mike Frysinger
2022-02-07 11:48 ` Corinna Vinschen
2022-02-07 19:30 ` Jeff Johnston [this message]
2022-02-08 1:57 ` [PATCH 0/6] delete i?86-pc-linux-gnu & libtool support Mike Frysinger
2022-02-08 1:57 ` [PATCH 1/6] newlib: drop i?86-pc-linux-* target support Mike Frysinger
2022-02-08 1:57 ` [PATCH 2/6] newlib: punt sys/linux support Mike Frysinger
2022-02-08 1:57 ` [PATCH 3/6] newlib: drop unused iconvdata Mike Frysinger
2022-02-08 4:55 ` Joel Sherrill
2022-02-08 1:57 ` [PATCH 4/6] newlib: drop libtool support Mike Frysinger
2022-02-08 9:47 ` Corinna Vinschen
2022-02-09 0:20 ` Mike Frysinger
2022-02-09 10:54 ` Corinna Vinschen
2022-02-09 8:41 ` Brian Inglis
2022-02-09 10:55 ` Corinna Vinschen
2022-02-08 1:57 ` [PATCH 5/6] newlib: drop support for $aext Mike Frysinger
2022-02-08 1:57 ` [PATCH 6/6] newlib: drop support for $oext Mike Frysinger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAOox84uJ6qchKGWxY2A1hzByXUSX+Ym_FLgyo8cWrnmDapSu=Q@mail.gmail.com' \
--to=jjohnstn@redhat.com \
--cc=newlib@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).