Library naming scheme: a resolution (for now)

[Yves Pelletier <ypell@cam.org>]

Hello folks,

I've taken a look at some issues surrounding the naming scheme,
and here is what I have come up with for now:

1. Lib names vs directories

For the time being, I will not make the official release of
the MiNTlib dependent on a given directory structure.  I will
change the lib names according to the following scheme:

c.a
bc.a
c16.a
bc1620.a, and so on.

The main reason for not going toward a directory-oriented
packaging at this time, is that this would break too many
Makefiles of existing packages: in many cases -m680x0 -m68881
arguments are not passed when ld is invoked, and it needs these
to go looking in the right directory.

Another reason is that IMO the linker should conform to the GCC
defaults for FPU settings.  For example, with

gcc -m68020 -c foo.c -o foo.o

the -m68881 switch is set by default even if it has not been
explicitely specified.  The linker should go looking for the lib
in /usr/lib/m68020/m68881.  Currently it will look in
/usr/lib/m68020 instead (which should really be the home for
libs compiled with -m68020 -nfp).  Even better, the linker
should look at the environment and assess the right default
switches.  In the case of a TT the linker should always assume
-m680[23]0 -m68881 unless told otherwise, and it should select
lib directories accordingly.

2. ID string vs MiNT ar

I think it would be a great idea to have an ID string in the
libs, so that, given file "libID", which contains a plain
character string,

ar r c.a libID ; ar p c.a libID

would yield something like: 

"MiNTlib PL49 m68020 m68881 absolute-addr long-int".

Also, subsequent calls such as: 

ar rs c.a foo.o

should work without problems.

This worked well in tests with HP-UX, Sun OS, and IRIX. 
However, MiNT ar aborts and complains that "libID" contains a
bad header and a badly formed string whenever the "s" switch is
used.  Until this is fixed I cannot go ahead with the ID string
idea. 

Regards,

Yves