Re: Boostrap fails on i386-pc-solaris2.10 - libquadmath error
Ralf Wildenhues ralf.wildenh...@gmx.de writes: the Automake manual can be read otherwise: ch. 8.3.7 `_LIBADD', `_LDFLAGS', and `_LIBTOOLFLAGS' states: As shown in previous sections, the `LIBRARY_LIBADD' variable should be used to list extra libtool objects (`.lo' files) or libtool libraries (`.la') to add to LIBRARY. The `LIBRARY_LDFLAGS' variable is the place to list additional libtool linking flags, such as `-version-info', `-static', and a lot more. *Note Link mode: (libtool)Link mode. There's nothing about external libraries specified with just -llib in the first sentence about _LIBADD. Well, later, in `Program and Library Variables', there is: `_LDADD' and `_LIBADD' are inappropriate for passing program-specific linker flags (except for `-l', `-L', `-dlopen' and `-dlpreopen'). Use the `_LDFLAGS' variable for this purpose. which hints at that -l is OK here. But independently of what's in the Automake manual, it is impossible to solve the ordering issues for static linking at the autotools level if -l can not be passed to _LIBADD, so we should improve the Automake manual if that is not explicit enough. I'd appreciate that. As I said, I could be persuaded to change this, but right now my primary interest is to get Solaris back to bootstrap land ASAP, and with less than 13000 testsuite failures ;-( Does this have to do anything with the issue at hand? The -lm in _LIBADD currently breaks the bootstrap. Unless there are strong objections, I'll shortly commit a patch to move it to _LDFLAGS for the time being (and fix the various issues with the quadmath.map-sun target at the same time). The testsuite failures are caused by some change in gcc/testsuite/lib; haven't yet looked which one. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Boostrap fails on i386-pc-solaris2.10 - libquadmath error
Tobias Burnus bur...@net-b.de writes:
No, finding libgfortran.spec at compile time works - it is all about
finding it at run time.
pardon me: AFAIK the spec files are *only* used by the compiler driver,
not at runtime of the resulting executables.
while my issue is about
finding the right (64-bit) libgcc_s.so.1 at runtime, due to a bug in the
construction of LD_LIBRARY_PATH in the testsuite. This worked before
and is broken now, due to the libquadmath patch.
I am not sure the bug is the same, but they are related. Both are about
finding the .spec file at run time; once for the installed system and once
No, they are not: LD_LIBRARY_PATH is only relevant for finding shared
objects at runtime and completely irrelevant to the compiler driver's
search for .spec files.
for the test-suite run. My plan is first to fix the first issue, namely
where the compiler searches for the library and then to revisit the test
suite issue.
The changes made can be shown via:
svn diff -r166824:166825 gcc/testsuite/lib/gfortran.exp
The changes are needed if the compiler is not installed, i.e. the libraries
are only in the build directory. In this case gfortran (the driver) needs
to be able to find the libgfortran.spec file based on the passed
-Ldir. The patch (cf. svn diff) is doing this, but seems to break the
test suite in some cases.
From a quick look, there seem to be several problems:
* libquadmath/.libs is added with -L and to LD_LIBRARY_PATH both if
libquadmath.a and again if libquadmath.${shlib_ext} exist. This would
explain why we see the unnecessary doubling of libquadmath/.libs in
LD_LIBRARY_PATH.
* Unfortunately, this doesn't take the multilib subdir into account,
which is wrong for the non-default multilib.
* Something seems to have been broken wrt. to
gcc-set-multilib-library-path since, as I wrote, gcc/amd64 isn't added
to LD_LIBRARY_PATH, which breaks all execution tests for the
non-default multilibs.
I'll further check what's going on here, adding a couple of log
statements to investigate.
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Boostrap fails on i386-pc-solaris2.10 - libquadmath error
On 11/19/2010 03:41 PM, Rainer Orth wrote:
Tobias Burnusbur...@net-b.de writes:
No, finding libgfortran.spec at compile time works - it is all about
finding it at run time.
pardon me: AFAIK the spec files are *only* used by the compiler driver,
not at runtime of the resulting executables.
Well, the spec files are used only by the driver - and neither by the
proper compiler (f951, cc1, etc.) nor by the generated executable.
However, besides the compiled in files, the driver also reads spec files
when it is run. That happens, e.g., for linking OpenMP (-fopenmp) or
since the addition of libquadmath for running gfortran. See your self:
Run:
echo end test.f90
gfortran -v -fopenmp test.f90 21 |grep -i spec
On my system that gives:
Using built-in specs.
Reading specs from
/projects/tob/gcc-trunk/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../libgfortran.spec
rename spec lib to liborig
Reading specs from
/projects/tob/gcc-trunk/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/../../../../lib64/libgomp.spec
[Side note: See the /lib/ instead of /lib64/? That's the driver bug I am
talking about.]
And the compiler driver (gfortran) needs to find the libgfortran.spec
file - otherwise, it simply aborts with an error message. As the
compiler might not be installed, if one runs the test suite, the .spec
file needs to be found by the compiler, e.g., by adding -Ldirectory to
the .spec file.
No, they are not: LD_LIBRARY_PATH is only relevant for finding shared
objects at runtime and completely irrelevant to the compiler driver's
search for .spec files.
Well, the LD_LIBRARY_PATH is not wrong because of the .spec file itself.
However, it is seemingly wrong because of a side effect in the patch
makes sure that the .spec file is found -- or because something goes
wrong with finding libquadmath. In any case, without the patch
gfortran simply aborts - that the LD_LIBRARY_PATH is correct, does not
help then.
The changes made can be shown via:
svn diff -r166824:166825 gcc/testsuite/lib/gfortran.exp
From a quick look, there seem to be several problems:
* libquadmath/.libs is added with -L and to LD_LIBRARY_PATH both if
libquadmath.a and again if libquadmath.${shlib_ext} exist. This would
explain why we see the unnecessary doubling of libquadmath/.libs in
LD_LIBRARY_PATH.
Granted. Though, shouldn't that also occur for libgfortran.*? Those
lines are copied from above.
* Unfortunately, this doesn't take the multilib subdir into account,
which is wrong for the non-default multilib.
I am not sure how it works for libgfortran (in the lines before
libquadmath). But as written, in terms of the .spec file there is also a
bug with regards to the driver, which I would like to fix first before
looking at the issues in gcc/testsuite/lib.
Tobias
Re: Boostrap fails on i386-pc-solaris2.10 - libquadmath error
On 11/18/2010 07:50 AM, Ralf Wildenhues wrote: * Rainer Orth wrote on Wed, Nov 17, 2010 at 09:15:55PM CET: * One cannot -lm to libquadmath_la_LIBADD since that gets passed to nm, which doesn't know (and doesn't need to be run) -lm. That's a bug in the rule using nm then, though. [...] Using *_LDFLAGS for -l flags is wrong though because it might mess up the ordering of libraries, at least for static linking. You might get away with this here because -lm is probably added from some other bit as well, but in general that is not a good idea. Do you have a better suggestion? And, do you have time to review my patch at: http://gcc.gnu.org/ml/gcc-patches/2010-11/msg01851.html Regarding the first part, i.e. whether libquadmath should only be build with Fortran or always, there is no consensus; so far I only saw two definite statements and a couple of no-opinions and a maybe-not, though for the latter it was not clear to me whether it was due to the build issues or going beyond. -- However, I am more interested in the second part, i.e. getting libquadmath to build with cross compilers and under Solaris. Tobias
Re: Boostrap fails on i386-pc-solaris2.10 - libquadmath error
Tobias Burnus bur...@net-b.de writes: Rainer Orth wrote: While the build completed with the patch I've posted, fortran testing for the non-default multilib is completely broken, e.g. That's in a way the a duplicate of PR 46516. Or at least the solution is I don't think so: this seems to be an issue finding libgfortran.spec at compile time (which seems to work for me), while my issue is about finding the right (64-bit) libgcc_s.so.1 at runtime, due to a bug in the construction of LD_LIBRARY_PATH in the testsuite. This worked before and is broken now, due to the libquadmath patch. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Boostrap fails on i386-pc-solaris2.10 - libquadmath error
Ralf Wildenhues ralf.wildenh...@gmx.de writes: * Rainer Orth wrote on Wed, Nov 17, 2010 at 09:15:55PM CET: * One cannot -lm to libquadmath_la_LIBADD since that gets passed to nm, which doesn't know (and doesn't need to be run) -lm. That's a bug in the rule using nm then, though. I'm not completely sure about this. One might skip such arguments in the contrib/make_sunver.pl script, though. Again, as in libjava/Makefile.am, I've moved it to libquadmath_la_LDFLAGS instead. Using *_LDFLAGS for -l flags is wrong though because it might mess up the ordering of libraries, at least for static linking. You might get away with this here because -lm is probably added from some other bit as well, but in general that is not a good idea. As I've mentioned in the submission of the patch that added Solaris-style symbol versioning to libjava [build, libjava] Support Sun symbol versioning in libjava http://gcc.gnu.org/ml/gcc-patches/2010-07/msg00073.html the Automake manual can be read otherwise: ch. 8.3.7 `_LIBADD', `_LDFLAGS', and `_LIBTOOLFLAGS' states: As shown in previous sections, the `LIBRARY_LIBADD' variable should be used to list extra libtool objects (`.lo' files) or libtool libraries (`.la') to add to LIBRARY. The `LIBRARY_LDFLAGS' variable is the place to list additional libtool linking flags, such as `-version-info', `-static', and a lot more. *Note Link mode: (libtool)Link mode. There's nothing about external libraries specified with just -llib in the first sentence about _LIBADD. As I said, I could be persuaded to change this, but right now my primary interest is to get Solaris back to bootstrap land ASAP, and with less than 13000 testsuite failures ;-( Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Boostrap fails on i386-pc-solaris2.10 - libquadmath error
* Rainer Orth wrote on Thu, Nov 18, 2010 at 06:32:59PM CET: Ralf Wildenhues ralf.wildenh...@gmx.de writes: * Rainer Orth wrote on Wed, Nov 17, 2010 at 09:15:55PM CET: * One cannot -lm to libquadmath_la_LIBADD since that gets passed to nm, which doesn't know (and doesn't need to be run) -lm. That's a bug in the rule using nm then, though. I'm not completely sure about this. One might skip such arguments in the contrib/make_sunver.pl script, though. That would be an alternative, yes. Using *_LDFLAGS for -l flags is wrong though because it might mess up the ordering of libraries, at least for static linking. You might get away with this here because -lm is probably added from some other bit as well, but in general that is not a good idea. As I've mentioned in the submission of the patch that added Solaris-style symbol versioning to libjava [build, libjava] Support Sun symbol versioning in libjava http://gcc.gnu.org/ml/gcc-patches/2010-07/msg00073.html the Automake manual can be read otherwise: ch. 8.3.7 `_LIBADD', `_LDFLAGS', and `_LIBTOOLFLAGS' states: As shown in previous sections, the `LIBRARY_LIBADD' variable should be used to list extra libtool objects (`.lo' files) or libtool libraries (`.la') to add to LIBRARY. The `LIBRARY_LDFLAGS' variable is the place to list additional libtool linking flags, such as `-version-info', `-static', and a lot more. *Note Link mode: (libtool)Link mode. There's nothing about external libraries specified with just -llib in the first sentence about _LIBADD. Well, later, in `Program and Library Variables', there is: `_LDADD' and `_LIBADD' are inappropriate for passing program-specific linker flags (except for `-l', `-L', `-dlopen' and `-dlpreopen'). Use the `_LDFLAGS' variable for this purpose. which hints at that -l is OK here. But independently of what's in the Automake manual, it is impossible to solve the ordering issues for static linking at the autotools level if -l can not be passed to _LIBADD, so we should improve the Automake manual if that is not explicit enough. As I said, I could be persuaded to change this, but right now my primary interest is to get Solaris back to bootstrap land ASAP, and with less than 13000 testsuite failures ;-( Does this have to do anything with the issue at hand? Anyway, I can look at things on Sunday if need be. Thanks, Ralf
Re: Boostrap fails on i386-pc-solaris2.10 - libquadmath error
Rainer Orth wrote: Tobias Burnusbur...@net-b.de writes: Rainer Orth wrote: While the build completed with the patch I've posted, fortran testing for the non-default multilib is completely broken, e.g. That's in a way the a duplicate of PR 46516. Or at least the solution is I don't think so: this seems to be an issue finding libgfortran.spec at compile time (which seems to work for me) No, finding libgfortran.spec at compile time works - it is all about finding it at run time. while my issue is about finding the right (64-bit) libgcc_s.so.1 at runtime, due to a bug in the construction of LD_LIBRARY_PATH in the testsuite. This worked before and is broken now, due to the libquadmath patch. I am not sure the bug is the same, but they are related. Both are about finding the .spec file at run time; once for the installed system and once for the test-suite run. My plan is first to fix the first issue, namely where the compiler searches for the library and then to revisit the test suite issue. The changes made can be shown via: svn diff -r166824:166825 gcc/testsuite/lib/gfortran.exp The changes are needed if the compiler is not installed, i.e. the libraries are only in the build directory. In this case gfortran (the driver) needs to be able to find the libgfortran.spec file based on the passed -Ldir. The patch (cf. svn diff) is doing this, but seems to break the test suite in some cases. Tobias
Boostrap fails on i386-pc-solaris2.10 - libquadmath error
Hi. My build this morning failed when libquadmath was being built. Things failed when configuring in the 'amd64' subdirectory - the bits below are taken from the 'config.log' in that directory: configure:3040: /export/home/arth/gnu/gcc-1117/./gcc/xgcc -B/export/home/arth/gnu/gcc-1117/./gcc/ -B/export/home/arth/local/i386-pc-solaris2.10/bin/ -B/export/home/arth/local/i386-pc-solaris2.10/lib/ -isystem /export/home/arth/local/i386-pc-solaris2.10/include -isystem /export/home/arth/local/i386-pc-solaris2.10/sys-include -m64 -V 5 xgcc: error: unrecognized option '-V' xgcc: fatal error: no input files compilation terminated. configure:3051: $? = 1 configure:3040: /export/home/arth/gnu/gcc-1117/./gcc/xgcc -B/export/home/arth/gnu/gcc-1117/./gcc/ -B/export/home/arth/local/i386-pc-solaris2.10/bin/ -B/export/home/arth/local/i386-pc-solaris2.10/lib/ -isystem /export/home/arth/local/i386-pc-solaris2.10/include -isystem /export/home/arth/local/i386-pc-solaris2.10/sys-include -m64 -qversion 5 xgcc: error: unrecognized option '-qversion' xgcc: fatal error: no input files compilation terminated. configure:3051: $? = 1 configure:3071: checking for C compiler default output file name configure:3093: /export/home/arth/gnu/gcc-1117/./gcc/xgcc -B/export/home/arth/gnu/gcc-1117/./gcc/ -B/export/home/arth/local/i386-pc-solaris2.10/bin/ -B/export/home/arth/local/i386-pc-solaris2.10/lib/ -isystem /export/home/arth/local/i386-pc-solaris2.10/include -isystem /export/home/arth/local/i386-pc-solaris2.10/sys-include -m64 -g -O2 conftest.c 5 configure:3097: $? = 0 configure:3134: result: a.out configure:3150: checking whether the C compiler works configure:3159: ./a.out /home/ahaas/gnu/gcc.git/libquadmath/configure: line 3161: ./a.out: cannot execute binary file configure:3163: $? = 126 configure:3170: error: in `/export/home/arth/gnu/gcc-1117/i386-pc-solaris2.10/amd64/libquadmath': configure:3174: error: cannot run C compiled programs. I see similar output in the 'config.log' files located in other subdirectories below 'amd64', but in those file subsquent lines indicate a test regarding cross-compiling. The build this morning on the sparc-sun-solaris2.10 machine worked without problems. My thanks to everyone working on GCC. Art Haas
Re: Boostrap fails on i386-pc-solaris2.10 - libquadmath error
Art Haas wrote: My build this morning failed when libquadmath was being built. Things failed when configuring in the 'amd64' subdirectory - the bits below are taken from the 'config.log' in that directory: There are two known problems: a) libquadmath should - at least for now - only be build by default if the --enable-languages encompasses fortran b) Building with a cross compiler is not supported by the libquadmath configure script They are both the consequence of adding libquadmath and thus Fortran REAL(16) support for some of the 32-bit x86/x86-64/ia64 targets. However, breaking the build was not intended. The two issues are tracked as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46520 Sorry for the breakage; it should be fixed soon. Tobias
Re: Boostrap fails on i386-pc-solaris2.10 - libquadmath error
* Tobias Burnus wrote on Wed, Nov 17, 2010 at 08:20:39PM CET: b) Building with a cross compiler is not supported by the libquadmath configure script http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46520 You should probably try out GCC_NO_EXECUTABLES in configure.ac and check with a couple of cross targets to find out whether you need to override any link checks with cache variables in the cross case. The symbol versioning test looks like it might qualify. OTOH libssp doesn't have cross measures for it either, so I'm not sure. Also, the test for __float128. It would be good to use configure cache variables (matching *_cv_*) for these (so the user can override them). Cheers, Ralf
Re: Boostrap fails on i386-pc-solaris2.10 - libquadmath error
Ralf Wildenhues ralf.wildenh...@gmx.de writes: * Tobias Burnus wrote on Wed, Nov 17, 2010 at 08:20:39PM CET: b) Building with a cross compiler is not supported by the libquadmath configure script http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46520 You should probably try out GCC_NO_EXECUTABLES in configure.ac and check with a couple of cross targets to find out whether you need to override any link checks with cache variables in the cross case. The symbol versioning test looks like it might qualify. OTOH libssp doesn't have cross measures for it either, so I'm not sure. Also, the test for __float128. It would be good to use configure cache variables (matching *_cv_*) for these (so the user can override them). I'm seeing none of those issues in a i386-pc-solaris2.10 build I've just fired off, but it still breaks in libquadmath: * The quadmath.map-sun target didn't use TABs before the commands, but blanks, which makes make choke: make[2]: Entering directory `/var/gcc/regression/trunk/10-gcc-gas/build/i386-pc-solaris2.10/libquadmath' Makefile:972: *** missing separator (did you mean TAB instead of 8 spaces?). Stop. * The sed command to mangle .la/.lo files into their .a/.o equivalents in .libs subdirs doesn't deal correctly with files in subdirs (like math, qdtoa). I've used the one from libjava/Makefile.am which does. * One cannot -lm to libquadmath_la_LIBADD since that gets passed to nm, which doesn't know (and doesn't need to be run) -lm. Again, as in libjava/Makefile.am, I've moved it to libquadmath_la_LDFLAGS instead. With those changed (the blank-to-TAB part isn't reflected in the diff), I could build both 32 and 64-bit libquadmath.so. I won't post a proper patch until it has completed, just a heads-up to those running into the same failures. Rainer --- Makefile~ 2010-11-17 20:53:03.037000370 +0100 +++ Makefile2010-11-17 21:01:53.426712881 +0100 @@ -281,8 +281,7 @@ LTLDFLAGS = $(shell $(SHELL) $(top_srcdi -no-undefined toolexeclib_LTLIBRARIES = libquadmath.la -libquadmath_la_LIBADD = -lm -libquadmath_la_LDFLAGS = $(LTLDFLAGS) -version-info `grep -v '^\#' $(srcdir)/libtool-version` $(version_arg) +libquadmath_la_LDFLAGS = $(LTLDFLAGS) -version-info `grep -v '^\#' $(srcdir)/libtool-version` $(version_arg) -lm libquadmath_la_LINK = $(LINK) $(libgfortran_la_LDFLAGS) libquadmath_la_DEPENDENCIES = $(version_dep) include_HEADERS = quadmath.h quadmath_weak.h @@ -971,8 +970,7 @@ quadmath.map-sun : $(srcdir)/quadmath.ma $(libquadmath_la_OBJECTS) $(libquadmath_la_LIBADD) perl $(top_srcdir)/../contrib/make_sunver.pl \ $(srcdir)/quadmath.map \ - $(libquadmath_la_OBJECTS:%.lo=.libs/%.o) \ - `echo $(libquadmath_la_LIBADD) | \ + `echo $(libquadmath_la_OBJECTS) $(libquadmath_la_LIBADD) | \ sed 's,\([^/]*\)\.l\([ao]\),.libs/\1.\2,g'` \ $@ || (rm -f $@ ; exit 1) -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Boostrap fails on i386-pc-solaris2.10 - libquadmath error
Rainer Orth r...@cebitec.uni-bielefeld.de writes: I won't post a proper patch until it has completed, just a heads-up to those running into the same failures. While the build completed with the patch I've posted, fortran testing for the non-default multilib is completely broken, e.g. Setting LD_LIBRARY_PATH to .:/var/gcc/regression/trunk/10-gcc-gas/build/i386-pc-solaris2.10/amd64/libgfortran/.libs:/var/gcc/regression/trunk/10-gcc-gas/build/i386-pc-solaris2.10/amd64/libgfortran/.libs:/var/gcc/regression/trunk/10-gcc-gas/build/i386-pc-solaris2.10/amd64/libquadmath/.libs:/var/gcc/regression/trunk/10-gcc-gas/build/i386-pc-solaris2.10/amd64/libquadmath/.libs:/var/gcc/regression/trunk/10-gcc-gas/build/gcc:.:/var/gcc/regression/trunk/10-gcc-gas/build/i386-pc-solaris2.10/amd64/libgfortran/.libs:/var/gcc/regression/trunk/10-gcc-gas/build/i386-pc-solaris2.10/amd64/libgfortran/.libs:/var/gcc/regression/trunk/10-gcc-gas/build/i386-pc-solaris2.10/amd64/libquadmath/.libs:/var/gcc/regression/trunk/10-gcc-gas/build/i386-pc-solaris2.10/amd64/libquadmath/.libs:/var/gcc/regression/trunk/10-gcc-gas/build/gcc:/var/gcc/regression/trunk/10-gcc-gas/build/i386-pc-solaris2.10/libstdc++-v3/src/.libs:/var/gcc/regression/trunk/10-gcc-gas/build/i386-pc-solaris2.10/libssp/.libs:/var/gcc/regression/trunk/10-gcc-gas/build/i386-pc-solaris2.10/libgomp/.libs:/var/gcc/regression/trunk/10-gcc-gas/build/./gcc:/var/gcc/regression/trunk/10-gcc-gas/build/./prev-gcc spawn [open ...] ld.so.1: achar_1.exe: fatal: /var/gcc/regression/trunk/10-gcc-gas/build/gcc/libgcc_s.so.1: wrong ELF class: ELFCLASS32 FAIL: gfortran.dg/achar_1.f90 -O0 execution test I've removed the builddir so the problems are easier seen: . i386-pc-solaris2.10/amd64/libgfortran/.libs i386-pc-solaris2.10/amd64/libgfortran/.libs i386-pc-solaris2.10/amd64/libquadmath/.libs i386-pc-solaris2.10/amd64/libquadmath/.libs gcc . i386-pc-solaris2.10/amd64/libgfortran/.libs i386-pc-solaris2.10/amd64/libgfortran/.libs i386-pc-solaris2.10/amd64/libquadmath/.libs i386-pc-solaris2.10/amd64/libquadmath/.libs gcc i386-pc-solaris2.10/libstdc++-v3/src/.libs i386-pc-solaris2.10/libssp/.libs i386-pc-solaris2.10/libgomp/.libs ./gcc ./prev-gcc The LD_LIBRARY_PATH above is broken in several ways: * gcc is added instead of gcc/amd64, so the default libgcc_s.so.1 multilib (32-bit in this case) is tried instead of the correct one. * target/amd64/libquadmath/.libs and target/amd64/libgfortran/.libs are added four times. * . is added twice, gcc even three times. * I've no idea why prev-gcc should be there. * The .libs directories for libstdc++-v3, libssp and libgomp are added for no good reason, and only for the default multilib, which is completely wrong. At the very least, the first issue needs to be fixed since it renders testresults useless with thousends of errors. I cannot investigate further myself since I'm on the way home. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Boostrap fails on i386-pc-solaris2.10 - libquadmath error
Rainer Orth wrote: While the build completed with the patch I've posted, fortran testing for the non-default multilib is completely broken, e.g. That's in a way the a duplicate of PR 46516. Or at least the solution is similar: Getting rid of libgfortran.spec and fall back (again) to having the compiler itself adding the -lquad. The only difficulty is: Having __float128 is not sufficient, one also needs to have some support libgcc. Thus, one needs to sort out how this is handled in gcc - and in particular in libgcc/config.host and gcc/config.gcc. Tobias, who disliked the solution of using libgfortran.spec with all the issues it caused.
Re: Boostrap fails on i386-pc-solaris2.10 - libquadmath error
* Rainer Orth wrote on Wed, Nov 17, 2010 at 09:15:55PM CET: * One cannot -lm to libquadmath_la_LIBADD since that gets passed to nm, which doesn't know (and doesn't need to be run) -lm. That's a bug in the rule using nm then, though. Again, as in libjava/Makefile.am, I've moved it to libquadmath_la_LDFLAGS instead. Using *_LDFLAGS for -l flags is wrong though because it might mess up the ordering of libraries, at least for static linking. You might get away with this here because -lm is probably added from some other bit as well, but in general that is not a good idea. Cheers, Ralf
