This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
RE: [PATCH libgloss]Using spec files to support two version of newlib library in one tool-chain release
- From: "Bin Cheng" <bin dot cheng at arm dot com>
- To: "'Jeff Johnston'" <jjohnstn at redhat dot com>, <newlib at sourceware dot org>
- Date: Thu, 14 Aug 2014 15:03:08 +0800
- Subject: RE: [PATCH libgloss]Using spec files to support two version of newlib library in one tool-chain release
- Authentication-results: sourceware.org; auth=none
- References: <001e01cfb600$ce404f10$6ac0ed30$ at arm dot com> <53EA3269 dot 1080304 at LGSInnovations dot com> <1407866624 dot 2601 dot 77 dot camel at ubuntu-sellcey> <000001cfb6b9$b6fa3690$24eea3b0$ at arm dot com> <20140813115827 dot GH21106 at calimero dot vinschen dot de> <165930362 dot 28789080 dot 1407948487418 dot JavaMail dot zimbra at redhat dot com>
> -----Original Message-----
> From: newlib-owner@sourceware.org [mailto:newlib-
> owner@sourceware.org] On Behalf Of Jeff Johnston
> Sent: Thursday, August 14, 2014 12:48 AM
> To: newlib@sourceware.org
> Subject: Re: [PATCH libgloss]Using spec files to support two version of newlib
> library in one tool-chain release
>
> ----- Original Message -----
> > From: "Corinna Vinschen" <vinschen@redhat.com>
> > To: newlib@sourceware.org
> > Sent: Wednesday, August 13, 2014 7:58:27 AM
> > Subject: Re: [PATCH libgloss]Using spec files to support two version
> > of newlib library in one tool-chain release
> >
> > On Aug 13 13:44, Bin Cheng wrote:
> > > > -----Original Message-----
> > > > From: newlib-owner@sourceware.org [mailto:newlib-
> > > > owner@sourceware.org] On Behalf Of Steve Ellcey
> > > > Sent: Wednesday, August 13, 2014 2:04 AM
> > > > To: Craig Howland
> > > > Cc: newlib@sourceware.org
> > > > Subject: Re: [PATCH libgloss]Using spec files to support two
> > > > version of
> > > newlib
> > > > library in one tool-chain release
> > > >
> > > > On Tue, 2014-08-12 at 11:27 -0400, Craig Howland wrote:
> > > >
> > > > > One thought on word choice for consideration: the new library
> > > > > files are named with an "_s" suffix, yet the option and file
> > > > > names use "nano", which has no letters in common with the _s.
> Presumably the "s"
> > > > comes from small or size.
> > > > > Might it be better to use "small" or "size" instead of "nano"?
> > > > > Or something else that more readily associates? (Not a big
> > > > > thing, but would become more important were another option to be
> > > > > added later.)
> > > > >
> > > > > Craig
> > > >
> > > > I would rather use the _n prefix to match nano rather then _s to
> > > > match
> > > small
> > > > (or size) because _s means 'shared' to me. The GCC build uses
> > > > foo.o for
> > > non-
> > > > pic objects and foo_s.o for pic objects when building some of its
> > > libraries like
> > > > libgcc. I think using _n would result in less confusion.
> > > >
> > > Hi,
> > > Thank both of you for the suggestion. I agree _s isn't appropriate
> > > here, and searched and replaced it with _n in the attached patch.
> > > If anyone thinks _n isn't clear enough I suggest we just use _nano
> > > here, since the word is used elsewhere in both file name and
> configuration option name.
> > >
> > > Is it OK for you guys?
> >
> > The patch looks good, but I think I'd prefer _nano as suffix. While
> > _s for "shared" is an established suffix, _n for a space optimized
> > version isn't. _nano would give a rather nice hint and would also
> > give credit to the actual code base.
> >
> > However, libgloss isn't exactly my domain, so I'd rather like to defer
> > to Jeff here. Perhaps the _n is ok as is.
> >
>
> I think _nano is better since the specs file is called called nano.specs and it is a
> new invention no one will be familiar with yet. The nano version of the
> library has some caveats that the end-user needs to understand so make it
> easier for them to find the documentation and understand what it is.
>
Thanks for the comments.
Here comes the patch using lib*_nana.a, please review.
Thanks,
bin
>
> -- Jeff J.