[PATCH libgloss]Using spec files to support two version of newlib library in one tool-chain release

[Corinna Vinschen]

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.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20140813/2723c949/attachment.sig>