Re: more gcc/mintlib questions

[Yves Pelletier <ypell@cam.org>]

On Thu, 12 Mar 1998, Howard Chu wrote:

> Perhaps a combined approach, just like terminfo uses - use
> both a unique filename *and* a directory hierarchy. Also, I
> have a preference for very short pathnames... 

If we do decide it is time for a new approach, this one sounds
quite good to me.  But I'm beginning to think we should aim for
PL49, not 48.  On another tack: I think Jan Paul's point, about
the .a extension, is valid - people know "c.a" is a library, but
may be puzzled if they find a "c.bs2" file lying around out of
context. We should probably keep the .a extension and just rely
on file name and directory structure to determine the
characteristics of a given library. 

<technical discussion deleted for brevity>

> Assuming we can define some precedence rules for how the linker can
> legitimately substitute, this could work very well. 

Seems to me you already did a lot of brush-clearing. :-)  I
really like the FPU emulation idea.  That, in itself, sounds
like a worthy undertaking. 

> I guess the only allowable substitutions are on the CPU version chain:
> 	68060 -> 68000
> The baserel vs absolute and short vs long are completely orthogonal.

<nodnod> So the directory structure should start with CPU type,
and then branch out according to the other, mutually exclusive,
characteristics.

> It strikes me that the user-mode changes from 68020 to 68060 are almost
> nonexistent, excluding FPU issues. Who really needs 68060-specific libc?

Gcc litterature hints at differences, in the discussion of the
-m68020-40 switch.  How significant they are, I'm not the best
qualified person to determine.  (Hmm. Also, isn't there some
sort of instruction problem in 68040 Mac ROMs that makes it
impossible to substitute a 68060 in the processor socket?)

Still, human nature being what it is, I think someone who owns a
68060 machine is going to want 68060 libraries :-). 

Yves
__
When the trees are seen to be moving, the enemy is advancing.
                                              Sun Tzu 9:20