[Build, Patch, libquadmath] PR 46520 Do not call AC_CHECK_LIB for gcc_no_link

[Build, Patch, libquadmath] PR 46520 Do not call AC_CHECK_LIB for gcc_no_link

[Tobias Burnus]

[-- Attachment #1: Type: text/plain, Size: 200 bytes --]

The title says all. I am not sure whether this patch is sufficient but 
it is the next step to fix the build. (The symbol-versioning check might 
still fail on bare irons.)

OK for the trunk?

Tobias

[-- Attachment #2: quad-build.diff --]
[-- Type: text/x-patch, Size: 858 bytes --]

2010-12-18  Tobias Burnus  <burnus@net-b.de>

	PR fortran/46520
	* configure.ac: Do not call AC_CHECK_LIB for gcc_no_link.
	* configure: Regenerate

diff --git a/libquadmath/configure.ac b/libquadmath/configure.ac
index 56b1fcb..603d2c1 100644
--- a/libquadmath/configure.ac
+++ b/libquadmath/configure.ac
@@ -109,8 +109,10 @@ esac
 AC_SUBST(toolexecdir)
 AC_SUBST(toolexeclibdir)
 
-AC_CHECK_LIB([m],[sqrtl],[AC_DEFINE([HAVE_SQRTL],[1],[libm includes sqrtl])])
-AC_CHECK_LIB([m],[cbrtl],[AC_DEFINE([HAVE_CBRTL],[1],[libm includes cbrtl])])
+if test x$gcc_no_link != xyes; then
+  AC_CHECK_LIB([m],[sqrtl],[AC_DEFINE([HAVE_SQRTL],[1],[libm includes sqrtl])])
+  AC_CHECK_LIB([m],[cbrtl],[AC_DEFINE([HAVE_CBRTL],[1],[libm includes cbrtl])])
+fi
 
 # Check for symbol versioning (copied from libssp).
 AC_MSG_CHECKING([whether symbol versioning is supported])

Re: [Build, Patch, libquadmath] PR 46520 Do not call AC_CHECK_LIB for gcc_no_link

[Ralf Wildenhues]

Hi Tobias,

* Tobias Burnus wrote on Sat, Dec 18, 2010 at 11:17:16AM CET:
> The title says all. I am not sure whether this patch is sufficient
> but it is the next step to fix the build. (The symbol-versioning
> check might still fail on bare irons.)
> 
> OK for the trunk?

Is the usage of the two HAVE_* defines for optimization only?
Then the patch is OK.  But you might still consider adding a case
statement in the gcc_no_link branch seeding the correct defines
or the respective configure cache variables (ac_cv_lib_m_cbrtl etc)
for targets where the functions are known to be available.

For configure choices that are not just used for optimization,
of course that becomes required procedure.

Thanks,
Ralf

> 2010-12-18  Tobias Burnus  <burnus@net-b.de>
> 
> 	PR fortran/46520
> 	* configure.ac: Do not call AC_CHECK_LIB for gcc_no_link.
> 	* configure: Regenerate
> 
> diff --git a/libquadmath/configure.ac b/libquadmath/configure.ac
> index 56b1fcb..603d2c1 100644
> --- a/libquadmath/configure.ac
> +++ b/libquadmath/configure.ac
> @@ -109,8 +109,10 @@ esac
>  AC_SUBST(toolexecdir)
>  AC_SUBST(toolexeclibdir)
>  
> -AC_CHECK_LIB([m],[sqrtl],[AC_DEFINE([HAVE_SQRTL],[1],[libm includes sqrtl])])
> -AC_CHECK_LIB([m],[cbrtl],[AC_DEFINE([HAVE_CBRTL],[1],[libm includes cbrtl])])
> +if test x$gcc_no_link != xyes; then
> +  AC_CHECK_LIB([m],[sqrtl],[AC_DEFINE([HAVE_SQRTL],[1],[libm includes sqrtl])])
> +  AC_CHECK_LIB([m],[cbrtl],[AC_DEFINE([HAVE_CBRTL],[1],[libm includes cbrtl])])
> +fi
>  
>  # Check for symbol versioning (copied from libssp).
>  AC_MSG_CHECKING([whether symbol versioning is supported])

Re: [Build, Patch, libquadmath] PR 46520 Do not call AC_CHECK_LIB for gcc_no_link

[Tobias Burnus]

[-- Attachment #1: Type: text/plain, Size: 501 bytes --]

Hi Ralf,

Ralf Wildenhues wrote:
> Is the usage of the two HAVE_* defines for optimization only?

Yes - it's just to speed up the calculation.

> But you might still consider adding a case
> statement in the gcc_no_link branch seeding the correct defines
> or the respective configure cache variables (ac_cv_lib_m_cbrtl etc)
> for targets where the functions are known to be available.

I have now use the configure cache variables; one can still add a 
version with switch, when needed.

OK?

Tobias

[-- Attachment #2: quad-link2.diff --]
[-- Type: text/x-patch, Size: 1175 bytes --]

2010-12-19  Tobias Burnus  <burnus@net-b.de>

	PR fortran/46520
	* configure.ac: Do not call AC_CHECK_LIB for gcc_no_link.
	* configure: Regenerate

diff --git a/libquadmath/configure.ac b/libquadmath/configure.ac
index 56b1fcb..68b5cf8 100644
--- a/libquadmath/configure.ac
+++ b/libquadmath/configure.ac
@@ -109,8 +109,19 @@ esac
 AC_SUBST(toolexecdir)
 AC_SUBST(toolexeclibdir)
 
-AC_CHECK_LIB([m],[sqrtl],[AC_DEFINE([HAVE_SQRTL],[1],[libm includes sqrtl])])
-AC_CHECK_LIB([m],[cbrtl],[AC_DEFINE([HAVE_CBRTL],[1],[libm includes cbrtl])])
+# If available, sqrtl and cbrtl speed up the calculation -
+# but they are not required
+if test x$gcc_no_link != xyes; then
+  AC_CHECK_LIB([m],[sqrtl],[AC_DEFINE([HAVE_SQRTL],[1],[libm includes sqrtl])])
+  AC_CHECK_LIB([m],[cbrtl],[AC_DEFINE([HAVE_CBRTL],[1],[libm includes cbrtl])])
+else
+  if test "x$ac_cv_lib_m_sqrtl" = x""yes; then
+    AC_DEFINE([HAVE_SQRTL],[1],[libm includes sqrtl])  
+  fi
+  if test "x$ac_cv_lib_m_cbrtl" = x""yes; then
+    AC_DEFINE([HAVE_CBRTL],[1],[libm includes cbrtl])  
+  fi
+fi
 
 # Check for symbol versioning (copied from libssp).
 AC_MSG_CHECKING([whether symbol versioning is supported])

Re: [Build, Patch, libquadmath] PR 46520 Do not call AC_CHECK_LIB for gcc_no_link

[Ralf Wildenhues]

* Tobias Burnus wrote on Sun, Dec 19, 2010 at 05:18:50PM CET:
> Ralf Wildenhues wrote:
> >Is the usage of the two HAVE_* defines for optimization only?
> 
> Yes - it's just to speed up the calculation.

Then the original patch is ok.

> >But you might still consider adding a case
> >statement in the gcc_no_link branch seeding the correct defines
> >or the respective configure cache variables (ac_cv_lib_m_cbrtl etc)
> >for targets where the functions are known to be available.
> 
> I have now use the configure cache variables; one can still add a
> version with switch, when needed.

Well, this patch is ok as well (and a bit nicer for users willing
to pass cache variables), but what I meant was something like

  # The toplevel --target becomes the --host in target libdirs.
  case $host_os in
    linux*) ac_cv_lib_m_sqrtl=yes ;;
    ...
  esac

that already seeds the variables on systems where the answer is known.
(Kind of like another step further.)

Cheers,
Ralf

> 2010-12-19  Tobias Burnus  <burnus@net-b.de>
> 
> 	PR fortran/46520
> 	* configure.ac: Do not call AC_CHECK_LIB for gcc_no_link.
> 	* configure: Regenerate
> 
> diff --git a/libquadmath/configure.ac b/libquadmath/configure.ac
> index 56b1fcb..68b5cf8 100644
> --- a/libquadmath/configure.ac
> +++ b/libquadmath/configure.ac
> @@ -109,8 +109,19 @@ esac
>  AC_SUBST(toolexecdir)
>  AC_SUBST(toolexeclibdir)
>  
> -AC_CHECK_LIB([m],[sqrtl],[AC_DEFINE([HAVE_SQRTL],[1],[libm includes sqrtl])])
> -AC_CHECK_LIB([m],[cbrtl],[AC_DEFINE([HAVE_CBRTL],[1],[libm includes cbrtl])])
> +# If available, sqrtl and cbrtl speed up the calculation -
> +# but they are not required
> +if test x$gcc_no_link != xyes; then
> +  AC_CHECK_LIB([m],[sqrtl],[AC_DEFINE([HAVE_SQRTL],[1],[libm includes sqrtl])])
> +  AC_CHECK_LIB([m],[cbrtl],[AC_DEFINE([HAVE_CBRTL],[1],[libm includes cbrtl])])
> +else
> +  if test "x$ac_cv_lib_m_sqrtl" = x""yes; then
> +    AC_DEFINE([HAVE_SQRTL],[1],[libm includes sqrtl])  
> +  fi
> +  if test "x$ac_cv_lib_m_cbrtl" = x""yes; then
> +    AC_DEFINE([HAVE_CBRTL],[1],[libm includes cbrtl])  
> +  fi
> +fi
>  
>  # Check for symbol versioning (copied from libssp).
>  AC_MSG_CHECKING([whether symbol versioning is supported])

Re: [Build, Patch, libquadmath] PR 46520 Do not call AC_CHECK_LIB for gcc_no_link

[Tobias Burnus]

Ralf Wildenhues wrote:
> Well, this patch is ok as well (and a bit nicer for users willing
> to pass cache variables), but what I meant was something like
>
>    # The toplevel --target becomes the --host in target libdirs.
>    case $host_os in
>      linux*) ac_cv_lib_m_sqrtl=yes ;;
>      ...
>    esac
>
> that already seeds the variables on systems where the answer is known.
> (Kind of like another step further.)

Is it obvious that all linux* support sqrtl? I wouldn't rule out that 
there are Linux systems with double-only LIBC. Admittedly, I rather 
would expect those on, e.g., ARM systems where no __float128 exists.

I have now committed the second version of the patch (Rev. 168069). 
However, if we find something better, one can still commit it as 
follow-up patch.

Tobias

Re: [Build, Patch, libquadmath] PR 46520 Do not call AC_CHECK_LIB for gcc_no_link

[Ralf Wildenhues]

* Tobias Burnus wrote on Sun, Dec 19, 2010 at 08:05:19PM CET:
> Ralf Wildenhues wrote:
> >   # The toplevel --target becomes the --host in target libdirs.
> >   case $host_os in
> >     linux*) ac_cv_lib_m_sqrtl=yes ;;
> >     ...
> >   esac

> Is it obvious that all linux* support sqrtl?

Oh, I have no idea about the actual settings; the above was only meant
as an example.

> I wouldn't rule out
> that there are Linux systems with double-only LIBC. Admittedly, I
> rather would expect those on, e.g., ARM systems where no __float128
> exists.

I would guess so, too.

> I have now committed the second version of the patch (Rev. 168069).
> However, if we find something better, one can still commit it as
> follow-up patch.

Thanks,
Ralf

Re: [Build, Patch, libquadmath] PR 46520 Do not call AC_CHECK_LIB for gcc_no_link

[Joseph S. Myers]

On Sun, 19 Dec 2010, Tobias Burnus wrote:

> Ralf Wildenhues wrote:
> > Well, this patch is ok as well (and a bit nicer for users willing
> > to pass cache variables), but what I meant was something like
> > 
> >    # The toplevel --target becomes the --host in target libdirs.
> >    case $host_os in
> >      linux*) ac_cv_lib_m_sqrtl=yes ;;
> >      ...
> >    esac
> > 
> > that already seeds the variables on systems where the answer is known.
> > (Kind of like another step further.)
> 
> Is it obvious that all linux* support sqrtl? I wouldn't rule out that there
> are Linux systems with double-only LIBC. Admittedly, I rather would expect
> those on, e.g., ARM systems where no __float128 exists.

On systems where double and long double have the same representation, 
sqrtl is an alias for sqrt.  The function exists in libm even though there 
is no declaration in the headers with FSF glibc (Jakub's patch to add the 
declarations as required by C99 was ignored).

-- 
Joseph S. Myers
joseph@codesourcery.com