------- Comment #23 from sgk at troutmask dot apl dot washington dot edu
2006-12-04 17:40 -------
Subject: Re: [4.1/4.2/4.3 regression] Unsatisfied symbol "fmodl" in
libgfortran shared library
On Mon, Dec 04, 2006 at 05:06:37PM -0000, ebotcazou at gcc dot gnu dot org
wrote:
>
>
> ------- Comment #22 from ebotcazou at gcc dot gnu dot org 2006-12-04 17:06
> -------
> > AFAIK, libgfortran has also assumed a C99 compiler/library is
> > available (even though gcc isn't C99 compliant). You'd need to
> > ping pbrook or stevenb about the details.
>
> s/also/always? In either case, that's not true, the 4.1.1 compiler works fine
> on Solaris 2.5.1, which is not C99 compliant at all, while 4.1.2pre is broken.
>
Yes, "always". Ping pbrook or stevenb. c99_function.c was
included to provide missing c99 routines on platforms that
needed them. 4.1.1 worked because people were careful with
adding missing functions. For example, I added round[f,l].
When rth fixed gfortran's determination of kind types,
gfortran suddenly grew real(10) or real(16) on many
platforms. It is assumed that the *l math functions
are available (e.g., cosl()). These math functions aren't
available on {Free,Open,Net}BSD, which I've been slowly
implementing under the 2-clause BSD license.
BTW, the patch should use libgfortran's internal round[f,l]
functions to avoid the significant loss of precision in
the current patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29810
