It seems so, yes. I don't know why openssh started using -O3.
p.
On Sun, 2004-06-13 at 20:11, Matthias Klose wrote:
So a workaround is to build using -O2 on arm (which should be the
default according to Debian policy anyway).
Philip Blundell writes:
Apparently this problem is triggered
On Sun, 2004-06-13 at 21:45, Colin Watson wrote:
On Sun, Jun 13, 2004 at 08:35:08PM +0100, Philip Blundell wrote:
On Sun, 2004-06-13 at 20:11, Matthias Klose wrote:
Philip Blundell writes:
Apparently this problem is triggered by -O3, which ssh has just started
using. I don't know
On Fri, 2004-04-09 at 16:37, Peter Naulls wrote:
gcc -Wp,-MD,arch/arm/boot/compressed/.ll_char_wr.o.d -nostdinc -iwithprefix
include -D__KERNEL__ -Iinclude
-D__KERNEL__ -Iinclude -D__ASSEMBLY__ -mlittle-endian -mapcs-32
-D__LINUX_ARM_ARCH__=3 -march=armv3
-mtune=strongarm110
On Fri, 2004-03-12 at 06:38, Matthias Klose wrote:
- Is 14302 the bug that caused XFree86 4.3 builds to fail on Debian ARM?
CCed Phil Blundell
No. The XFree86 problem was also in GO_IF_LEGITIMATE_ADDRESS, but this
was a different bug. I don't think we had a PR filed for the XFree86
thing.
On Fri, 2004-03-12 at 12:08, Richard Earnshaw wrote:
Phil, were you going to commit the back-port you had done?
Yep, I can do that.
p.
On Mon, 2003-09-22 at 23:58, Matt Zimmerman wrote:
It is a problem for us to ship binary packages that we cannot build. What
happens if we needed to do an urgent update on this package (e.g.,
security)? Or if a user needs to patch and rebuild it?
From what I recall, fixing libstdc++3 to
On Fri, 2003-06-27 at 18:54, Daniel Jacobowitz wrote:
On Thu, Jun 26, 2003 at 06:09:07PM +0100, Philip Blundell wrote:
On Wed, 2003-06-25 at 21:13, Bill Allombert wrote:
A wild guess : '@ lr needed for prologue'
mean that lr must not be clobbered but
'ldrb lr, [r0, #3]' clobber
On Wed, 2003-06-25 at 21:13, Bill Allombert wrote:
A wild guess : '@ lr needed for prologue'
mean that lr must not be clobbered but
'ldrb lr, [r0, #3]' clobber it (??)
Yes, exactly that. Thanks for isolating this problem!
I'll take a look at the code and see if I can come up with a fix,
On Thu, 2003-06-19 at 16:26, Bill Allombert wrote:
Package: gcc-3.3
Version: 1:3.3-3
Severity: normal
Dear GCC maintainers,
gcc 3.3 (1:3.3ds9-3) miscompile pari (2.1.5) on arm with -O3, whereas
gcc 3.2 (3.2.3 20030331) worked fine.
With -O2 gcc 3.3 works fine also
The preprocessed
On Fri, 2003-06-20 at 10:24, Marcelo E. Magallon wrote:
(sid)[EMAIL PROTECTED]:~/gts-0.7.1/src$ gcc -DHAVE_CONFIG_H -I. -I. -I.. -I..
-I/usr/include -DG_LOG_DOMAIN=\Gts\ -O2 -Wall -Wall
-Werror-implicit-function-declaration -Wstrict-prototypes
-Wmissing-prototypes -Wmissing-declarations
So, per our IRC discussion this afternoon, I think the current plan for
this is to have ld.so treat CMOV as an optional extension, similar to
how MMX is handled. In other words:
- Add CMOV to HWCAP_IMPORTANT in glibc.
- Ask the maintainers of openssl and any other affected packages to put
Package: gcc-3.1
Version: 1:3.1.1ds3-3
Severity: serious
Justification: arm autobuilder can't cope otherwise
Autoconf 2.50 doesn't seem to work for building gcc 3.1 (it triggers the
recursion limit reached problem). For gcc-3.0, changing the build
dependency from autoconf to autoconf2.13 fixed
Package: gcc-3.1
Version: 1:3.1.1ds3-3
Severity: serious
libstdc++ doesn't compile with glibc 2.3 headers. Its locale-related
files make copious use of symbols that are no longer declared (e.g.
__strtod_l, __newlocale, __ctype_toupper).
On Fri, 2002-11-15 at 12:41, Martin v. Loewis wrote:
Philip Blundell [EMAIL PROTECTED] writes:
Autoconf 2.50 doesn't seem to work for building gcc 3.1 (it triggers the
recursion limit reached problem). For gcc-3.0, changing the build
dependency from autoconf to autoconf2.13 fixed
On Tue, 2002-09-03 at 00:19, James Troup wrote:
'cos you had already uploaded a newer version by the time it had
finished building. If foo_1.0-1 gets built, it'll only be uploaded as
long as 1.0-2 (source) hasn't gone into the archive. I suppose I
could manually upload the old version, but
On Tue, 2002-09-03 at 17:27, LaMont Jones wrote:
Bug #158290 talks about an issue with gcc 3.0 on hppa. Specifically,
building perl 5.8 with -O2 fails tests, while -O1 works.
Any thoughts on the subject? mawk also suffers from the same ailment.
Try gcc 3.1 or 3.2?
p.
On Tue, 2002-08-27 at 12:40, Junichi Uekawa wrote:
On Tue, 27 Aug 2002 13:14:30 +0200
Laurent Bonnaud [EMAIL PROTECTED] wrote:
LD_LIBRARY_PATH=/tmp/LB/gcc-3.2-3.2ds0/build/gcc/ada \
/usr/bin/make -C /tmp/LB/gcc-3.2-3.2ds0/build/gcc gnatlib gnattools
It should probably be
On Wed, 2002-08-14 at 08:08, Martin Schulze wrote:
Package: gcc-3.2
Version: current
Severity: minor
- Description: The GNU C compiler
+ Description: GNU Compiler Collection 3.2
It's called GNU Compiler Collection since 1999, btw/fyi.
That's indeed the name of the upstream project.
Package: gcc-2.95
Version: 1:2.95-7
Severity: important
Tags: fixed
Profiling does not work on ARM with gcc 2.95. There are two problems:
- the cc1 specs seem to be missing %{profile:-p}, so -profile doesn't
actually enable profiling code generation (though -p/-pg works)
- the generated
On Mon, 2002-06-10 at 13:15, Ulrich Eckhardt wrote:
Package: libstdc++3-dbg
Version: 3.0.4-7
While trying to debug a program, I encountered some weird paths that
prevented me from taking advance of the debug-lib:
LD_PRELOAD=/usr/lib/libstdc++_debug/libstdc++3.so.3 gdb ./test
...
(gdb)
On Mon, 2002-06-10 at 22:04, Chris Cheney wrote:
Does anyone know if/when Debian is planning on switching the default
compiler to gcc 3.1.x. I am waiting to upload KDE 3 to see if gcc 3.1
will become the default compiler anytime soon.
At some point during the next major release cycle, yes.
On Sun, 2002-06-09 at 20:26, Martin v. Loewis wrote:
I don't think that a Debian bug report is the right place to push a
patch into gcc (i.e. to lobby for it).
Instead, you should assume that all patches that have been submitted
to gcc-patches are implicitly Debian bug reports which already
On Wed, 2002-05-29 at 14:47, Othmar Pasteka wrote:
i tested searchandrescue on arm with gcc 3.1. it worked,
Oh, cool. Want to try realtimebattle as well? :-)
p.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
On Mon, 2002-05-06 at 19:35, Matthew Wilcox wrote:
I've tried building m68k-linux, arm-linux and alpha-linux gnat compilers.
None has worked ;-( ARM and m68k seem to be missing some exception handling
support, eg (arm):
../../xgcc -B../../ -c -DCROSS_COMPILE -DIN_GCC `echo -g -O2
On Sat, 2002-04-06 at 00:13, Matthias Klose wrote:
Philip Blundell writes:
On Tue, 2002-04-02 at 11:04, Matthias Klose wrote:
- arm: missing(?) arm-patches
I sent the two patches we had in 3.0 to the gcc mailing lists. Maybe
there's still a chance that they might be included
On Sat, 2002-04-06 at 20:17, Samuel Tardieu wrote:
| - More architectures: Chris wrote, he wanted to build for alpha.
| Anyone else for other architectures?
Cross compilation needed, not difficult, only tedious.
Is there a recipe somewhere for bringing up GNAT using a cross compiler?
I'm
On Fri, 2002-04-05 at 08:16, Zdenek Kabelac wrote:
Hmm looks like it - but there are two interesting points however
- somehow I've not noticed this report while using reportbug
- I do not link libGLU to avifile - but as it's linked with libSDL
libGL seems to be linked with the program - but
On Tue, 2002-04-02 at 11:04, Matthias Klose wrote:
- arm: missing(?) arm-patches
I sent the two patches we had in 3.0 to the gcc mailing lists. Maybe
there's still a chance that they might be included in the actual
release. If not, it's no big deal.
Yesterday I ran a build of the 3.1 package
On Mon, 2002-04-01 at 16:44, Jeff Bailey wrote:
Do you folks have pre-release gcc-3.1 debs that we can use for testing
(and possibly building...)? A quick google search doesn't seem to
show any recent discussion on this, so if there's somewhere better I
need to look, please let me know.
reassign 139796 localepurge
thanks
On Fri, 2002-03-29 at 01:55, Mark Montague wrote:
Date: Fri, 29 Mar 2002 08:10:06 +0900
From: Junichi Uekawa [EMAIL PROTECTED]
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: Bug#139796: gij-3.0: fails to configure when localepurge has
removed
tags 140186 + unreproducible
thanks
I'm not able to replicate this bug. Can you send a complete test-case
that shows the problem?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
: low
Maintainer: Debian GCC maintainers debian-gcc@lists.debian.org
Changed-By: Philip Blundell [EMAIL PROTECTED]
Description:
chill-2.95 - The GNU CHILL compiler.
cpp-2.95 - The GNU C preprocessor.
cpp-2.95-doc - Documentation for the GNU C preprocessor (cpp).
g++-2.95 - The GNU C++ compiler
-defaults (0.19) unstable; urgency=medium
* Set g77 version for ARM to 3.0.
* Disable java for mips(el); it clearly isn't getting built.
* Add self to Uploaders
-- Philip Blundell [EMAIL PROTECTED] Sun, 3 Mar 2002 22:36:36 +
and the rules patch is:
--- gcc-defaults-0.18/debian/rules
On Wed, 2002-02-27 at 19:27, Matthias Klose wrote:
Philip Blundell writes:
On Wed, 2002-02-27 at 17:04, Adam C Powell IV wrote:
3.0 fixes this problem, but then maintainers must hand-build using
g77-3.0, which is not a viable long-term solution. I know some arches
have 3.0
On Mon, 2002-02-25 at 21:51, Blars Blarson wrote:
On Mon, Feb 25, 2002 at 09:39:13PM +, Philip Blundell wrote:
There is no point just trying to pin the blame on arbitrary packages.
The fact that libstdc++2.10-dev won't configure is a symptom of the
problem, not the cause.
I don't
On Tue, 2002-02-12 at 22:20, Frederic Tessier wrote:
We are not familiar with the intricate workings of the compiler,
but this must have to do with an alignment problem when the
executable is launched, as the changes typically occur when the
name length is increased by 8 bytes. This is a
tags 130422 + patch
thanks
see http://gcc.gnu.org/ml/gcc-patches/2002-02/msg00627.html
plus some earlier analysis at
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=viewdatabase=gccpr=4860
i am by no way a gcc literate person, so i just want to point out
that the latest gcc-2.95 version doesn't build on arm, see the
build logs on
http://buildd.debian.org/fetch.php?pkg=gcc-2.95ver=2.95.4.ds8-1arch=armsta
mp=1010333265file=logas=raw
for further details.
Yeah, Matthias and I are
The version of gpc in the 2001-12-23 upload doesn't seem to work on arm,
sparc, m68k or s390; they all seem to segfault somewhere during the build.
../.././xgpc -B../.././ -c -I. -W -Wall -Wpointer-arith -Wwrite-strings
-Wmissing-prototypes -Wmissing-declarations -g -O3
Does anybody know what the deal is here?
p.
--
if [ -x debian/patches/libffi-install.dpatch ]; then true; else chmod +x
debian/patches/libffi-install.dpatch; fi
if [ -f stamps/02-patch-stamp-libffi-install ]; then \
echo libffi-install patches already applied.; exit 1; \
fi
What's the hold-up on the sid-woody move for gcc-3.0 (I haven't seen
update-excuses yet)? I can't think of any reason to keep the version in
woody around at all...
It has an RC bug, #105246. Update-excuses also mentions some problem with the
doc packages but this looks like it may be spurious.
# these are bad, but not release critical
severity 105246 important
severity 103980 important
thanks
pgpLAocCVxWEe.pgp
Description: PGP signature
#103980- [PR c++/3702] gcc-3.0 copies constructors, a build error
in the sfs package.
#105246:- [PR c++/3774 arm] can't compile a trivial program including
string
I just downgraded those two to important. They have been forwarded upstream,
they aren't
No, we aren't talking about nouns, we are talking about acronyms. The above
does not pertain to this use.
An acronym is still a noun. (And 80s isn't an acroynm, anyway.)
p.
pgpU4M3HJgHOm.pgp
Description: PGP signature
isnt it called GNU Compiler Collection?
http://packages.debian.org/unstable/devel/gcc-3.0.html
Well, yes and no. The gcc package really is the GNU C Compiler, but its
description is a bit confusing. I'll update this in CVS. Thanks for the
report.
p.
pgpk22SnfWv83.pgp
Description: PGP
Phil disabled the softfloat package for arm, m68k doesn't build (yet),
the other architectures don't built with multilibs configured. Let's
Yeah. I turned it off for arm because it isn't much use (and indeed prevents
the package from building) if you don't also have a soft-float version of
I think our current gcc 2.95.4 is stable enough, and sufficiently better
than the 2.95.2 in potato, that we should consider making new packages to go
into 2.2r4 or whatever the next version is going to be. I guess this should
be straightforward enough to achieve.
Anybody object to this? If
the current 2.95.4 doesn't builf on s390, but 2.95.3, so it might be
necessary to add a reverse-diff (for woody as well).
Is there any bug open for this? I couldn't find one from a quick look at the
lists for gcc and gcc-2.95. In any case I don't think we have to worry about
it for potato --
I sincerely doubt that this will ever get past the Release Manager
unless you have a very good, very specific reason. I recommend talking
to him before spending your time.
I think it's worth making the packages even if the Release Manager (who is
that for potato these days, anyway?) won't
I think you need to add libgc5-dev to the gcc build-depends.
Without that package installed, the package build fails in objc.
gcc-2.95_2.95.4.ds1-0.010506 has:
Build-Depends: dejagnu (= 1.3-19990614), bzip2, binutils (= 2.11.90.0.1-1),
deb
helper (= 2), gperf (= 2.7-3), autoconf (= 2.13),
Okay... I'll look into this again in a couple of weeks... Let's give
time to the autobuilders...
It's not actually a case of the autobuilders being behind; the current 3.0
package doesn't compile on ARM because of some soft-float related lossage.
I think I fixed the copy of the rules in CVS
Package: gcc-2.95
Version: 1:2.95.3-11
This patch fixes a problem compiling binutils on ARM. It's already installed
on the 2.95 branch in CVS, but if future packages are going to use the 2.95.3
tarball it would be good to have this included.
#! /bin/sh -e
# DP: Fix for SUBREG problems
just uploaded a 2.95.4 package from the branch to incoming. This will
fix #91823 as well?
Oh, right, cool. Yes, it's the same bug.
btw, could you have a look at #90363?
Yeah, I'd forgotten about that one. Fortran is in pretty bad shape on ARM,
and I don't hold out all that much hope of
53 matches
Mail list logo
