Re: more gcc/mintlib questions

[hyc@troy.la.platsol.com (Howard Chu)]

  Speaking of which, I spent an hour or so yesterday, updating the
  most glaringly obsolete bits in the MiNTlib FAQ; I will post
  that to my ftp site later today.

  ftp://ftp.cam.org/users/ypell  

  Also, unless there are objections, as of PL48 I will change the
  naming convention to something like: c.a, c16.a, bc.a, ... ,
  bc16020.a.  This appears necessary because people have to change
  the names of the lib to make it work with newer gcc.  If I am
  missing something, advice is welcome.

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

Any comments?
  -- Howard