On 11/19/2010 03:41 PM, Rainer Orth wrote:
Tobias Burnus 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 fi
Tobias Burnus 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) li
Ralf Wildenhues 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
>> (`.
Rainer Orth wrote:
Tobias Burnus 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 b
* Rainer Orth wrote on Thu, Nov 18, 2010 at 06:32:59PM CET:
> Ralf Wildenhues 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.
> >
>
Ralf Wildenhues 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 su
Tobias Burnus 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
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
* 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
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
th
Rainer Orth 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/g
Ralf Wildenhues 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 configu
* 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 cr
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 b
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/
15 matches
Mail list logo
