Some background is here, for Sun internal people.

LSARC/1992/005  Bundled libm packaging  Dean Stanton    closed approved 7/7/93  
Unpublished
LSARC/1993/668  SPARCompilers 3.0.1     Evan Adams      closed approved summary 
Unpublished

I suspect things have changed more than a little in the last 17 years.

It would be more useful to focus our time on deciding what to do next.

Alan's point is well taken.  The normal way to enforce standards compliance
is to do it at compile time via include files and predefines.  The compiler
helps with this via -xc99 and -X options for example.


keith bierman wrote:
> 
> Alan Coopersmith:
>>
>>
>> Wouldn't it be more consistent to follow the libc model, where all the
>> functions, both standard and non-standard, are in the same .so, but the
>> function prototypes are visible or hidden based on the #defines set?
>>
> Memory can be a fickle thing, but I believe libsunmath predates some of
> the facilities required. The split goes back pretty far, pre-Solaris I
> think (using the customary definition of Solaris 2.0+ as Solaris ... I
> think the first compiler releases with libsunmath were 4.1.x based, and
> had to run in both environments for several years).
> 
>  Of course, my old email discussion threads were destroyed (I presume)
> by IT when I left. David Hough, Alex Liu, Gregory Tarsy, et al. probably
> have a better chance of resurrecting the original decision making than
> anyone outside of Sun\\\\Java.
> 
>> --
>>         -Alan Coopersmith-           alan.coopersmith at sun.com
>>          Sun Microsystems, Inc. - X Window System Engineering
>>
> ------------------------------------------------------------------------
> The information contained in this transmission may be confidential. Any
> disclosure, copying, or further distribution of confidential information
> is not permitted unless such privilege is explicitly granted in writing
> by Quantum Corporation. Furthermore, Quantum Corporation is not
> responsible for the proper and complete transmission of the substance of
> this communication or for any delay in its receipt.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> tools-compilers mailing list
> tools-compilers at opensolaris.org

Reply via email to