Package: g++
Version: 2:2.95.4-14 (or what s390 used, see below)
Severity: normal
My QuantLib package doesn't build on s390. Buildd shows the following towards
the end of the log:
make[3]: Entering directory `/build/buildd/quantlib-0.3.0/Examples/Swap'
source='swapvaluation.cpp' object='swapval
uildd logs have more as well.
Dirk
On Sun, Jan 05, 2003 at 02:49:39PM -0600, John W. Eaton wrote:
> On 5-Jan-2003, Dirk Eddelbuettel <[EMAIL PROTECTED]> wrote:
>
> |
> | >From the build log, and note that I already switch debugging and
> optimisation
> | off on m6
Here are further details on the "g77-3.2 dies on m68k" bug, as suggested by
John and Rick.
Dirk
Script started on Sun Jan 5 22:35:20 2003
[EMAIL PROTECTED]:~$ cd octave2.1-2.1.43/libcruft/amos/
[EMAIL PROTECTED]:~/octave2.1-2.1.43/libcruft/amos$ gcc-3.2 -v
Reading specs from /usr/lib/gcc-lib/m6
> Dirk Eddelbuettel writes:
> >
> > Package: g77-3.2
> > Version: +N/A; reported 2003-01-05
> > Severity: important
> >
> > This applies to g77-3.2 on m68k as detailed below in an email I first sent
> > to the m68k build crew, and John Eaton, Octa
Folks,
Did we already report this one upstream? Note the -O0 -g0, not sure what
else I can try, other than to shoot all the four remaining linux-on-m68k
users left on the planet. Just kidding.
Dirk
Details taken from
http://buildd.debian.org/fetch.php?&pkg=octave2.1&ver=2.1.45-1&arch=m68k&s
> Dirk Eddelbuettel writes:
> >
> > Folks,
> >
> > Did we already report this one upstream?
>
> see #175478, submitted by someone called Edd ... ;-)
Ah, yes, amnesia hitting me squarely on the forehead. Thanks for the
cluebat,
> > Note the -O0 -g0,
As per follow-up email, the bug still haunts us ...
/usr/bin/g77-3.2 -c -fPIC -O0 -g0 zbknu.f -o pic/zbknu.o
zbknu.f: In subroutine `zbknu':
zbknu.f:567: Internal compiler error in instantiate_virtual_regs_1, at
function.c:3980
Please submit a full bug report,
with preprocessed source if appropr
On 26 October 2007 at 17:44, Martin Michlmayr wrote:
| * Bastian Blank <[EMAIL PROTECTED]> [2007-10-26 17:07]:
| > Nack. quantlib-swig feeds insane large input and fails.
|
| Does that s390 buildd only have 256 MB of RAM or so?
Good point. I've seen the g++ process approach one gb on my x86 when
On 26 October 2007 at 20:02, Martin Michlmayr wrote:
| * Dirk Eddelbuettel <[EMAIL PROTECTED]> [2007-10-26 11:30]:
| > Also of note is that powerpc fails with ICE whereas it managed to build the
| > previous Debian upload 0.8-2
|
| voltaire only has 320 MB RAM, so I guess it's s
Using -O0 and -g0 avoided the ICE on s390 as seen at
http://buildd.debian.org/build.php?&pkg=quantlib-swig&ver=0.8.0-4&arch=s390&file=log
I'll leave it to the g++ maintainers to see if they want to close this, or
look at it further. It may really just be a resource exhaustion on the host
machine
On 27 October 2007 at 15:55, Matthias Klose wrote:
| Dirk Eddelbuettel writes:
| >
| > On 26 October 2007 at 20:02, Martin Michlmayr wrote:
| > | * Dirk Eddelbuettel <[EMAIL PROTECTED]> [2007-10-26 11:30]:
| > | > Also of note is that powerpc fails with ICE whereas it
On 27 October 2007 at 17:12, Luigi Ballabio wrote:
|
| On Oct 27, 2007, at 4:36 PM, Dirk Eddelbuettel wrote:
| > |
| > | the correct fix is to make the code chunks which swig generates,
| > smaller.
| >
| > I'll let upstream know (CC'ed, hi Luigi :).
|
| Hi, Dirk
Package: g++-4.1
Version: 4.1.1-5
Severity: important
The g++ version that recently entered testing exhibits the same problem I had
been reported to the hppa maintainers -- and which Randolph report upstream
at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28620 .
I understand that it is fixed in
(With the 14hr mail outage on master.debian.org, this is the first message I
am seeing in this thread after I filed my bug report. So forgive me if I say
something redundant...).
On 17 August 2006 at 12:00, Martin Michlmayr wrote:
| * John Schmidt <[EMAIL PROTECTED]> [2006-08-16 18:32]:
| > I hav
On 18 August 2006 at 00:58, Martin Michlmayr wrote:
| * John Schmidt <[EMAIL PROTECTED]> [2006-08-17 13:46]:
| > Is there a way for me to instrument my code/system, etc to indicate
| > where the big time sink is?
|
| I'm not sure but I'll try to investigate.
I didn't make that as clear as I want
On 19 August 2006 at 15:03, Matthias Klose wrote:
| Dirk Eddelbuettel writes:
| >
| > On 18 August 2006 at 00:58, Martin Michlmayr wrote:
| > | * John Schmidt <[EMAIL PROTECTED]> [2006-08-17 13:46]:
| > | > Is there a way for me to instrument my code/system, etc to indicate
On 22 August 2006 at 07:29, Dirk Eddelbuettel wrote:
|
| On 19 August 2006 at 15:03, Matthias Klose wrote:
| | Dirk Eddelbuettel writes:
| | >
| | > On 18 August 2006 at 00:58, Martin Michlmayr wrote:
| | > | * John Schmidt <[EMAIL PROTECTED]> [2006-08-17 13:46]:
| | > | >
On 3 September 2006 at 14:40, Martin Michlmayr wrote:
| * Dirk Eddelbuettel <[EMAIL PROTECTED]> [2006-09-03 06:47]:
| > I never heard any follow-up. Is there any? While it is nice that 4.1.1-11
is
| > now in testing it is not so nice that 4.1.1-11 exhibits the slow builds John
|
On 3 September 2006 at 16:27, Martin Michlmayr wrote:
| * Dirk Eddelbuettel <[EMAIL PROTECTED]> [2006-09-03 09:16]:
| > | up with some kind of (small) testcase.
| >
| > As John and I stated, 'small' is hard to define in the context of large-ish
| > C++ applications
One interesting little illustration is provided by the CRAN timing
summaries. The master site of CRAN (the CTAN / CPAN equivalent for R) is
hosted on Debian testing. Compile/build/test times are shown at
http://cran.r-project.org/src/contrib/checkTimings.html
and RQuantLib is the 2nd most time
On 5 September 2006 at 18:41, Luigi Ballabio wrote:
|
| On Sep 3, 2006, at 5:57 PM, Dirk Eddelbuettel wrote:
| > | s/small/self-contained/ then. Do you have some example where the
| > | linking process of some c++ files takes ages, without linking them
| > | against some external libra
On 26 September 2006 at 11:34, John Schmidt wrote:
| To follow-up on my experiences with g++-4.1 code and extremely slow link
| times, I did a chroot and pulled in old versions of g++-4.1 and binutils from
| snapshot.debian.net to build my big c++ application.
|
| Here is a table with the follo
On 26 September 2006 at 20:10, Martin Michlmayr wrote:
| * Dirk Eddelbuettel <[EMAIL PROTECTED]> [2006-09-26 13:07]:
| > Nice work, and I can surely try this. Now, I don't see a recent non-2.17
| > version of binutils anywhere in .deb form for i386. Before I go off an
| > rebu
Hi Martin,
On 19 April 2007 at 16:51, Martin Michlmayr wrote:
| * Dirk Eddelbuettel <[EMAIL PROTECTED]> [2006-08-15 17:29]:
| > Package: g++-4.1
| > Version: 4.1.1-5
| >
| > I understand that it is fixed in unstable, but as the toolchain is
| > frozen (or being frozen) I j
On 19 April 2007 at 20:12, Martin Michlmayr wrote:
| Dirk,
|
| * Dirk Eddelbuettel <[EMAIL PROTECTED]> [2007-04-19 20:44]:
| > No beans. I was just discussing with Kurt Hornik, one of the R Core
| > developers, and CRAN maintainers, why building of my RQuantLib /
| > r-cran-qu
I put up a new revision quantlib_0.8.1-2 which builds better on some arches
(mips, mipsel) but dies on arm with
make[4]: Entering directory `/build/buildd/quantlib-0.8.1/ql'
/bin/sh ../libtool --tag=CXX --mode=link g++ -O0 -g0 -D_REENTRANT -fpermissive
-o libQuantLib.la -rpath
/build/buildd/
On Wed, Jul 18, 2007 at 04:22:03PM +0200, Matthias Klose wrote:
> Dirk Eddelbuettel writes:
> > Shouldn't that have been g++ 4.2 anyway?
>
> why?
I thought it was the default in unstable.
Dirk
--
Hell, there are no rules here - we're tryin
On 18 July 2007 at 18:24, Aurelien Jarno wrote:
| Dirk Eddelbuettel a écrit :
| > I put up a new revision quantlib_0.8.1-2 which builds better on some arches
| > (mips, mipsel) but dies on arm with
| >
| > make[4]: Entering directory `/build/buildd/quantlib-0.8.1/ql'
| > /bin
Package: gcc-4.2
Severity: important
Version: 4:4.2.1-6
The new gsl sources (1.90.90-1) failed on Alpha with the following error:
/bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H
-I. -I.. -I.. -I..-mieee -mfp-rounding-mode=d -Wall -pipe -fexceptions
-D_REENTRANT -g -O3 -mieee
On Wed, Sep 12, 2007 at 08:04:22PM +0200, Matthias Klose wrote:
> Dirk Eddelbuettel writes:
> > Please submit a full bug report,
> > with preprocessed source if appropriate.
>
> please do so, does it build with gcc-snapshot?
Don't know as I don't have access to A
On 12 September 2007 at 21:00, Falk Hueffner wrote:
| Dirk Eddelbuettel <[EMAIL PROTECTED]> writes:
|
| > /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H
| > -I. -I.. -I.. -I..-mieee -mfp-rounding-mode=d -Wall -pipe -fexceptions
| > -D_REENTRANT -g -O3 -mieee
reassign 94137 gcc
thanks
Ok, this one might be easy to close for the gcc folks as it appears to fixed
in newer versions; I am reassigned mostly for record keeping purposes.
Thanks, Dirk
"Andras" == Major A writes:
Andras> SUMMARY
Andras>
Andras> Thanks all for the debugging info. Th
On Wed, Feb 27, 2002 at 07:35:32AM +0100, Matthias Klose wrote:
> Debian Bug Tracking System writes:
> > Processing commands for [EMAIL PROTECTED]:
> >
> > > reassign 135943 gcc
> > Bug#135943: r-recommended_1.4.1-1 fails to autobuild on m68k
> > Bug reassigned from package `r-recommended' to `gcc
On Wed, Feb 27, 2002 at 12:29:15PM +, Phil Blundell wrote:
> On Wed, 2002-02-27 at 02:40, Dirk Eddelbuettel wrote:
> > gcc -I/usr/lib/R/include -fPIC -g -O2 -c coxfit2.c -o coxfit2.o
> > coxfit2.c: In function `coxfit2':
> > coxfit2.c:352: Internal compile
On Wed, Feb 27, 2002 at 04:16:36PM +, Phil Blundell wrote:
> On Wed, 2002-02-27 at 13:03, Dirk Eddelbuettel wrote:
> > On Wed, Feb 27, 2002 at 12:29:15PM +, Phil Blundell wrote:
> > > On Wed, 2002-02-27 at 02:40, Dirk Eddelbuettel wrote:
> > > > gcc -I/usr/l
have successfully built hundreds of times on different platforms.
-
From: "John W. Eaton" <[EMAIL PROTECTED]>
Date: Wed, 24 Apr 2002 13:03:07 -0500
To: Dirk Eddelbuettel <[EMAIL PROTECTED]>
Subject: internal
> > There appear to (still) be some issues with g++-3.0 on ia64. Under some
> > optimisation switches, the executable is built, but segfaults. Under others,
> > g++-3.-0 dies.
>
> fwiw with gcc version 3.1 20020331 (prerelease) the problem appears to
> be fixed. I think this might be the same/re
See
http://buildd.debian.org/fetch.php?&pkg=octave-forge&ver=2004.01.18-1&arch=mips&stamp=1074506653&file=log&as=raw
for more details, the pertinent part is
mkoctfile -DHAVE_OCTAVE_21 -v lp.cc
/usr/bin/g++ -c -fPIC -I/usr/include/octave-2.1.52
-I/usr/include/octave-2.1.52/octave -O2 -DHAVE_OCTA
On Tue, Jan 20, 2004 at 07:16:54PM +, Martin Michlmayr wrote:
> * Dirk Eddelbuettel <[EMAIL PROTECTED]> [2004-01-20 11:06]:
> > mkoctfile -DHAVE_OCTAVE_21 -v lp.cc
> > /usr/bin/g++ -c -fPIC -I/usr/include/octave-2.1.52
> > -I/usr/include/octave-2.1.52/octave -O2 -DH
On Sat, Jun 19, 2004 at 03:56:22PM +0200, Kurt Roeckx wrote:
> On Sat, Jun 19, 2004 at 08:48:37AM -0500, Dirk Eddelbuettel wrote:
> >
> > arch := $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
>
> Shouldn't you be using the DEB_BUILD_GNU_TYPE instead? (It
> r
40 matches
Mail list logo
