From: Tristan Gingold <gingold@adacore.com>
To: Ralf Corsepius <ralf.corsepius@rtems.org>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>, fortran@gcc.gnu.org
Subject: Re: [Patch] libgfortran: do not assume libm
Date: Tue, 20 Mar 2012 10:16:00 -0000 [thread overview]
Message-ID: <2F4AC48A-E696-4622-B0E8-EC8B22333BE0@adacore.com> (raw)
In-Reply-To: <4F685446.5030204@rtems.org>
On Mar 20, 2012, at 10:56 AM, Ralf Corsepius wrote:
> On 03/20/2012 10:01 AM, Tristan Gingold wrote:
>> Hi,
>>
>> I am starting to build fortran for VMS.
>>
>> The first serious issue was with libgfortran/configure. It checks for several math functions, but directly in libm using AC_CHECK_LIB.
>> But there is on such things as libm on VMS systems (thus requiring to define MATH_LIBRARY as ""). Therefore all these tests fail,
>> resulting in a failure during libgfortran build.
>>
>> I think the best way to test for the math function is to use AC_CHECK_DECLS as hinted by the autoconf manual
>> (cf the AC_CHECK_DECLS example in http://www.gnu.org/software/autoconf/manual/autoconf.html
>> AC_CHECK_DECLS([j0], [], [], [[#include<math.h>]])
>> AC_CHECK_DECLS([[basename(char *)], [dirname(char *)]])
>>
>> )
>> but I am not an autoconf expert.
>>
>> I think that this change makes the AIX specific check for __clog obsolete, but I haven't removed it.
>>
>> With this change I was able to cross build libgfortran for VMS (ia64 and alpha).
>> I have also bootstrapped gcc for x86_64-darwin, without fortran regressions.
>>
>> Ok for trunk ?
>
> IMO, no.
>
> What you are doing here is to replace checks, which check for presence of a symbol in a library (e.g. cos in libm.*) by checks for presence of a symbol's declaration inside of a header.
>
> This is something entirely different (This also reflects in AC_CHECK_DECL by default providing HAVE_DECL_XXX defines).
Ah, indeed. I missed that.
> Also note that it's not uncommon to have declarations inside of headers, which are not present inside of a library.
So, I should use AC_LINK_IFELSE instead, shouldn't I ?
Tristan.
next prev parent reply other threads:[~2012-03-20 10:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-20 9:02 Tristan Gingold
2012-03-20 9:58 ` Ralf Corsepius
2012-03-20 10:16 ` Tristan Gingold [this message]
2012-03-20 9:49 Tobias Burnus
2012-03-20 9:57 ` Tristan Gingold
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2F4AC48A-E696-4622-B0E8-EC8B22333BE0@adacore.com \
--to=gingold@adacore.com \
--cc=fortran@gcc.gnu.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=ralf.corsepius@rtems.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).