Patchwork Additional RFC, Re: RFC automatic linkage of libquadmath with gfortran: PR driver/46516; libgfortran.spec, multilib search path

mail settings
Submitter IainS
Date Nov. 25, 2010, 11:11 a.m.
Message ID <>
Download mbox | patch
Permalink /patch/73040/
State New
Headers show


IainS - Nov. 25, 2010, 11:11 a.m.
Hello all...

On 22 Nov 2010, at 07:28, Tobias Burnus wrote:

> On 11/22/2010 12:07 AM, Michael Matz wrote:
>> I have another improvement here.  I'm regularly testing uninstalled
>> compilers (or compilers installed in temp paths).  This exposed a  
>> problem
>> in that the .spec file is only found when the proper -L option is  
>> given
>> (that's okay), which it usually isn't for non-linking commands.  In  
>> that
>> case lang_specific_pre_link is nevertheless called, tries to include
>> libgfortran.spec and fails.  Hence, let's remember if we're in a  
>> non-link
>> run, and not do anything with that .spec file.
>> Regstrapping on x86_64-linux in progress.  Okay if that passes?
> OK. Thanks for the patch!

I have some requested additions (for Darwin), but also some  

Firstly, when one hijacks *lib, it means that the target has no chance  
to do spec substitutions/outfile removal
-- this is because the new libs are added after "output files" have  
been evaluated in the LINK_COMMAND.
-- because libs are not treated as switches, one cannot switch on them  

So that means that we must ensure:
(a) that we don't add any libs that the target doesn't want
(b) if there are any substitutions, unfortunately they need to appear  
in the libgfortran spec - since we can't hide them away in the target  

      if test -f ../libquadmath/; then


Thoughts? OK for trunk?
(tested on *-darwin9, and x86_64-unk-linux)



Firstly, I wonder if it would be better to hijack the   
"*link_gcc_c_sequence" rather than "*lib"
(this means that the correct link sequence for libgcc/lc will follow  
directly after the libgfortran/libquadmath sequence .
... which also means one doesn't have to embed any differences in the  
way targets make that sequence)

like this:

--- libgfortran/	(revision 167142)
+++ libgfortran/	(working copy)
@@ -2,7 +2,10 @@ 
  # This spec file is read by gfortran when linking.
  # It is used to specify the libraries we need to link in, in the right
  # order.

-%rename lib liborig
-*lib: @LIBQUADSPEC@ -lm %(libgcc) %(liborig)
+# Hijack the link sequence for libgcc and lc so that we can interpose
+# the quad math and system math libs just before it. This also works  
+# targets that only link lgcc once.
+%rename link_gcc_c_sequence link_gcc_c_sequence_orig
+*link_gcc_c_sequence: @LIBQUADSPEC@ @LIBMSPEC@ % 

If that's not OK - then we need to suppress the additional %(libgcc)  
for darwin too.

NOTE;  I think that if we do this we can lose all the libm agonizing  
from gfortranspec.c - because the libgfortan.spec will automatically  
place "-lm" just before the libgcc/lc sequence for targets that  
require it.
(If the user inserts a '-lm' by hand we should just pass that through  
-  on the assumption that the user knows what (s)he is doing).


Secondly to cater for  Darwin (and any other target that doesn't want - 
lm unconditionally);
(plus our spec substitution for the static case)

Index: libgfortran/
--- libgfortran/	(revision 167142)
+++ libgfortran/	(working copy)
@@ -515,6 +515,17 @@  else

+# Allow for targets which don't need/want -lm.
+case "${host}" in
+  *-darwin*)
+    ;;
+  *)
+    LIBMSPEC="-lm"
+    ;;
  # Write our Makefile and spec file.

Index: libgfortran/acinclude.m4
--- libgfortran/acinclude.m4	(revision 167142)
+++ libgfortran/acinclude.m4	(working copy)
@@ -329,7 +329,10 @@  AC_DEFUN([LIBGFOR_CHECK_FLOAT128], [
      if test "x$libgfor_cv_have_as_needed" = xyes; then
        LIBQUADSPEC="%{static-libgfortran:--as-needed} -lquadmath % 
-      LIBQUADSPEC="-lquadmath"
+      case "${target}" in
+        *86*-*-darwin*) LIBQUADSPEC="%{static|static-libgcc|static- 
libgfortran: libquadmath.a%s; : -lquadmath}" ;;
+        *) LIBQUADSPEC="-lquadmath" ;;
+      esac