Re: more gcc/mintlib questions

[Yves Pelletier <ypell@cam.org>]

On Wed, 11 Mar 1998, Howard Chu wrote:

> I like this idea, I just wonder if we can make our naming scheme even
> more compact. "bc16020.a" seems like an awful lot of junk for "libc,
> base relative, 16 bit int, 68020 instructions". (OK, I suppose it's
> better than what I just spelled out.) Or maybe we just have too messy
> an environment, and we have to live with it. 
> 
> We might consider just single-character tokens for 16 bit int and 68020,
> e.g. 's' for short int, and '2' for 68020 libs. I'm also thinking about
> putting these in the suffix, instead of the filename, e.g.
> 	c.a, c.as, c.a2, c.as2
> 
> Of course, we need a convention for the order of the tokens... The above
> is only a suggestion.
> 
> Assuming this strategy is acceptable, the base-relative libs could be
> 	c.b, c.bs, c.b2, c.bs2
> 
> (Since really the ".a" suffix is arbitrary, and pretty much a throwaway
> anyway, it conveys no real information.)
> 
> One advantage of this approach is that you don't have to change your
> "-l" arguments to the linker, (assuming the linker is modified to
> understand these suffixes) when you change compiler options. (E.g.,
> you would have to change -lc to -lc020 or whatever, the way we do things
> now.)

No major objections...  just wondering about the linker.  It
would have to be made available at the same time as the new
libs, to minimize confusion.  Also, if we take your idea a bit
further, we might want the linker to recognize -m680x0 switches
and search for the most appropriate library available on the
system.  For instance, if someone compiles a program with the
-m68060 switch, perhaps it would be appropriate for the linker
to first search for a c.a6 library, and then downgrade all the
way to c.a if necessary.  What do you think?

Yves