On Tue, Mar 24, 2009 at 12:27 AM, Andy Dougherty <[email protected]> wrote:
> On Mon, 23 Mar 2009, Rolf Grossmann wrote:
>
>> Andy Dougherty wrote:
>> > > > #include <math.h>
>> > > > #if defined(__GNUC__) && defined(_LIB_VERSION)
>> > > >    _LIB_VERSION_TYPE _LIB_VERSION = _IEEE_;
>> > > > #endif
>> > > >
>> > > > Maybe _LIB_VERSION is not defined?
>> >
>> > It is not solved by that bit of code.  At least on Solaris 8, _LIB_VERSION
>> > is not defined.  Nor is _LIB_VERSION_TYPE.  That bit of code is just
>> > irrelevant.  It has never been useful there.  It was worth trying, but it
>> > doesn't do anything.
>>
>> But that bit of code might be the hint we're looking for. In my math.h on
>> Solaris 10 there are these definitions:
>>
>> enum version {libm_ieee = -1, c_issue_4, ansi_1, strict_ansi};
>> extern const enum version _lib_version;
>>
>> wrapped in
>>
>> #if defined(__EXTENSIONS__) || !defined(_XOPEN_SOURCE)
>>
>> So I've verified that Solaris cc has a method of either setting or
>> linking against a correct constant for _lib_version with -xlibmieee.
>> Unfortunately it really is constant, so trying to trick it just results
>> in a segfault :( A quick Google search didn't give me any hints either
>> and I haven't had the time to dig deeper, yet.
>
> On Solaris 8, here's how it seems to work:  The value of libm_ieee can
> have one of those four values you quote above.  Those values are set in
> the object files  /usr/ccs/lib/values-X*.o.  On my system, there are
> five such files:
>     File        _lib_version   atan2(-0.0, -0.0)   Purpose
>    values-Xa.o     1             0                 ANSI + K&R extensions
>    values-Xc.o     2             0                 strict conformant ANSI
>    values-Xs.o     0             0 (DOMAIN error)  K&R only
>    values-Xt.o     0             0 (DOMAIN error)  K&R + ANSI transitional
>    values-xpg4.o  -1             -3.14159          XPG4 compliance
>
> (These files are mostly named after corresponding cc(1) flags; for
> example cc -Xc gives strict ANSI conformance.)
>
> Further, if you have installed Sun's compiler, there is an additional
> files values-xi.o under /opt/SUNWspro/
>
>    values-xi.o    -1             -3.14159          IEEE-754 compliance
>
> What the -xlibmieee flag does for Sun's compiler is have the linker
> replace values-Xa.o by values-xi.
>
> For gcc, the file values-Xa.o appears to be hard-wired in to the
> built-in specs.  The only way to change it appears to be to override it
> with a custom specs file.  Hmm.  That might not be too hard.  We just
> create a file (I'll call it 'parrot-gcc.specs') with the following two
> lines:
>
>    *startfile_arch:
>    %{ansi:values-Xc.o%s}                   %{!ansi:values-xpg4.o%s}
>
> and then add  -specs=parrot-gcc.specs to $linkflags.
> (if values-xi.o is available, that might be a better choice.)
>
> It's not *too* messy.  What do you think?  (Hmm.  It might get messy
> for installation, however -- where do we put the specs file so that
> languages that build against parrot know how to pick it up?)
>

OK, well now I guess I have a new project for myself on Perl 5 one of
these day.  Thanks for digging into the nasty little bits left for
this bug.

Steve Peters
[email protected]
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev

Reply via email to