Package: src:gcc-14
Version: 14-20240121-1
Severity: important
Tags: sid trixie ftbfs
X-Debbugs-CC: debian-arm@lists.debian.org
gcc-14 ftbfs on armel. This is a long standing, re-occurring issue
which never has been forwarded and committed by the armel ports to GCC
upstream. Please do it.
[
Package: ftp.debian.org
X-Debbugs-CC: debian-arm@lists.debian.org
Please remove the armel and mips64el binaries of creduce and cvise.
Going forward with LLVM-17, which is ftbfs on these architectures, with
no feedback from the port maintainers (armel), or no feedback from
upstream (mips64el).
On 24.11.23 07:19, Emanuele Rocca wrote:
Hello!
On 2023-11-24 01:34, Guillem Jover wrote:
According to https://bugs.debian.org/918914#73 there were no pending
toolchain issues related to this.
That is correct. The GCC maintainers at Arm confirm that
stack-clash-protection is supported on 32 b
Hi,
it looks like enabling this flag on armel/armhf is a little bit premature.
Apparently it's not completely supported upstream, and might cause
regressions, according to
https://bugzilla.redhat.com/show_bug.cgi?id=1522678
Is that a feature that the Debian ARM32 porters and the security team
Package: src:llvm-toolchain-17
Version: 1:17.0.5-1
Severity: important
Tags: sid trixie
X-Debbugs-CC: debian-arm@lists.debian.org
see
https://buildd.debian.org/status/fetch.php?pkg=llvm-toolchain-17&arch=armel&ver=1%3A17.0.4-1&stamp=1698822562&raw=1
FAILED: projects/openmp/runtime/src/CMakeFiles
Link time optimizations are an optimization that helps with a single digit
percent number optimizing both for smaller size, and better speed. These
optimizations are available for some time now in GCC. Link time optimizations
are also at least turned on in other distros like Fedora, OpenSuse (
On 11/9/21 21:41, Sergio Durigan Junior (@sergiodj) wrote:
>
>
>
> Sergio Durigan Junior commented:
>
>
> When I was investigating this problem I had many links open to GCC docs and
> whatnot, but I closed all of those tabs now. Either way, using
> `-mfpu=vfpv3-d16` seems to be the best opt
Package: src:gcc-snapshot
Version: 1:20210827-1
Severity: important
Tags: sid bullseye
X-Debbugs-CC: debian-arm@lists.debian.org
GCC trunk (12.0) ftbfs on armel:
[...]
/<>/build/gcc/ada/rts/s-atopri.adb:80: undefined reference to
`__atomic_load_8'
collect2: error: ld returned 1 exit status
gnatli
On 12/1/20 5:02 AM, YunQiang Su wrote:
> I am sorry for the later response.
>Hi,
>
> I am an active porter for the following architectures and I intend
> to continue this for the lifetime of the Bullseye release (est. end
> of 2024):
>
> For mipsel and mips64el, I
> - test most pac
Debian bullseye will be based on a gcc-10 package taken from the gcc-10 upstream
branch, and binutils based on a binutils package taken from the 2.35 branch.
I'm planning to make gcc-10 the default after gcc-10 (10.2.0) is available
(upstream targets mid July). binutils will be updated before mak
On 27.12.19 18:35, Julien Puydt wrote:
> Package: g++-9
> Version: 9.2.1-21
>
> I have a package which fails to build on both Debian armel and mipsel
> with this g++ package, and with the same error:
> /usr/bin/ld: ./.libs/libfplll.so: undefined reference to
> `__atomic_store_8'
> /usr/bin/ld: ./.
GCC 9 was released earlier this year, it is now available in Debian
testing/unstable. I am planning to do the defaults change in mid August, around
the time of the expected first GCC 9 point release (9.2.0).
There are only soname changes for rather unused shared libraries (libgo)
involved, and the
The recent gcc-8 and gcc-9 uploads to unstable are now built using pgo and lto
optimization. Not on all architectures, see debian/rules.defs. On the plus
side the compilers are 7-10% faster, however the build time of the compiler is
much longer, adding 10-20 hours. If people feel that this isn't
On 13.04.19 17:01, Joerg Jaspert wrote:
> On 15371 March 1977, Aurelien Jarno wrote:
>
>>> How is the move to debian-ports supposed to happen? I won't have the
>>> time to do anything about it within the 2 weeks.
>
>> The process to inject all packages to debian-ports is to get all the
>> deb, ud
On 10.04.19 10:29, Adrian Bunk wrote:
> On Wed, Apr 10, 2019 at 10:11:29AM +0200, Matthias Klose wrote:
>> Package: src:llvm-toolchain-7
>> Version: 1:7.0.1-8
>> Severity: serious
>> Tags: sid buster
>>
>> underlinked clang libraries on armel cause build f
Package: src:llvm-toolchain-7
Version: 1:7.0.1-8
Severity: serious
Tags: sid buster
underlinked clang libraries on armel cause build failures, as seen at
https://buildd.debian.org/status/package.php?p=creduce
/usr/bin/ld:
/usr/lib/llvm-7/lib/libclangFrontend.a(SerializedDiagnosticReader.cpp.o):
u
On 07.07.18 17:24, YunQiang Su wrote:
> Niels Thykier 于2018年6月28日周四 上午4:06写道：
>> List of concerns for architectures
>> ==
>>
>> The following is a summary from the current architecture qualification
>> table.
>>
>> * Concern for ppc64el and s390x: we are dependent
GCC 8 is available in testing/unstable, and upstream is approaching the first
point release. I am planning to make GCC 8 the default at the end of the week
(gdc and gccgo already point to GCC 8). Most runtime libraries built from GCC
are already used in the version built from GCC 8, so I don't ex
According to [1], binutils 2.31 (currently in experimental) will branch in about
a week, and I'll plan to upload the branch version to unstable. Test results
are reported to [2], these look reasonable, except for the various mips targets,
however as seen in the past, it doesn't make a differenc
On 26.09.2017 10:48, Edmund Grimley Evans wrote:
> Package: gcc-6-arm-linux-gnueabi
> Version: 6.3.0-18cross1
>
> This is not specific to cross-compiling and not even to gcc-6.
>
> We noticed the infinite loop when the buildd tries to build rnahybrid:
>
> https://buildd.debian.org/status/logs.ph
On 06.08.2017 11:04, John Paul Adrian Glaubitz wrote:
> On 08/06/2017 05:00 PM, John Paul Adrian Glaubitz wrote:
>> I am currently testing the updated patch on armel, armhf and
>> m68k. If it succeeds, it should be included for the next upload
>> and the workaround for m68k from #868255 [1].
>
> .
On 30.06.2017 15:22, Adrian Bunk wrote:
> On Thu, Jun 29, 2017 at 02:37:27PM +0200, Matthias Klose wrote:
>> On 29.06.2017 06:51, Adrian Bunk wrote:
>>> Package: libstdc++6
>>> Version: 7.1.0-7
>>> Severity: serious
>>> Control: affects -1 src:mesa
>
On 29.06.2017 06:51, Adrian Bunk wrote:
> Package: libstdc++6
> Version: 7.1.0-7
> Severity: serious
> Control: affects -1 src:mesa
>
> mesa FTBFS on armel due to:
>
> https://buildd.debian.org/status/fetch.php?pkg=mesa&arch=armel&ver=17.1.3-2&stamp=1498610882&raw=0
>
> ...
> llvm-config-4.0: re
Apparently X-Debbugs-CC doesn't add up, so the ports lists didn't get a
notification yet ...
Please see
#845159 [i| | ] [src:gcc-7] gcc-7: gnat fails to build on kfreebsd-*
#861734 [i| | ] [src:gcc-7] gcc-7 fails to build gnattools on armel
#861735 [i| | ] [src:gcc-7] gcc-7 fails to build g
[CCing porters, please also leave feedback in #835148 for non-release
architectures]
On 29.09.2016 21:39, Niels Thykier wrote:
> Hi,
>
> As brought up on the meeting last night, I think we should try to go for
> PIE by default in Stretch on all release architectures!
> * It is a substantial har
On 20.09.2016 23:46, John Paul Adrian Glaubitz wrote:
> On 09/20/2016 11:16 PM, Niels Thykier wrote:
>>- powerpc: No porter (RM blocker)
>
> I'd be happy to pick up powerpc to keep it for Stretch. I'm already
> maintaining powerpcspe which is very similar to powerpc.
No, you are not maintaini
On 15.09.2016 22:43, Helge Deller wrote:
> Hi Matthias,
>
> On 10.09.2016 00:48, Matthias Klose wrote:
>> While the Debian Release team has some citation about the quality of the
>> toolchain on their status page, it is not one of the release criteria
>> documented
&
On 10.09.2016 09:59, Paul Gevers wrote:
> Hi,
>
> On 10-09-16 00:48, Matthias Klose wrote:
>> - fpc not available on powerpc anymore (may have changed recently)
>
> For whatever it is worth, this was finally fixed this week. It is
> missing on mips*, ppc64el and s390
On 10.09.2016 10:21, Simon McVittie wrote:
> On Sat, 10 Sep 2016 at 00:48:09 +0200, Matthias Klose wrote:
>> The arm-linux-gnueabi is not that well defined, so it may include the hard
>> float
>> variant as well. However Debian default to armv4t, while the default
>>
While the Debian Release team has some citation about the quality of the
toolchain on their status page, it is not one of the release criteria documented
by the release team. I'd like to document the status how I do understand it for
some of the toolchains available in Debian.
I appreciate that t
On 09/04/2015 03:38 AM, Rob Browning wrote:
> Rob Browning writes:
>
>> You mean -O0, perhaps?
>
> Actually, there may be a mistake in the current rules file which is
> causing it to always build without an -O flag...
>
> Changing the rules to work correctly (to use -O2 as you mentioned)
> appe
Control: tags -1 + wontfix
armel's cpu default is too old to support this. so live with it.
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55450a9a.8010...@debian.org
Control: tags -1 + help
this is not seen on the gcc-4.9 Linaro branch, so a ARM porter should identify
the relevant backport.
On 12/25/2014 06:12 AM, Matthias Klose wrote:
> the escalation is wrong. there exist several workarounds for it (lowering the
> optimization, using gcc-4.8, ...). I
the escalation is wrong. there exist several workarounds for it (lowering the
optimization, using gcc-4.8, ...). I asked the ARM porters to address this
properly (Hector on IRC agreed to forward this), however I don't see any
progress here. Now CCing debian-arm explicitly.
On 12/23/2014 11:48 AM,
On Sat, Jul 12, 2014 at 00:08:28 +0900, Osamu Aoki wrote:
> But this seems toi be a bug porter amd GCC maintainer has to address.
> If they can not, we should drop armel from Debian.
I would rather drop any package which does use c++11 features without any
reflection. The c++11 status in GCC (and
t;> "just know" what to do, but I haven't the slightest idea of where to begin.
>> I have a box with gcc-4.9, plenty of disk space, and electricity to burn.
>> Where do I start?
>>
>> Patrick
>>
>>
>>> On Thu, May 8, 2014 at 10:25 AM, M
With gcc-4.9 now available in testing, it is time to prepare for the change of
the default to 4.9, for a subset of architectures or for all (release)
architectures. The defaults for the gdc, gccgo, gcj and gnat frontends already
point to 4.9 and are used on all architectures. Issue #746805 tracks
Control: reopen -1
Control: severity -1 important
Control: tags -1 + help
you applied a work around, but didn't fix the issue. Please keep the issue open
until it is addressed.
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact li
Am 27.12.2013 03:16, schrieb Steve McIntyre:
> On Thu, Dec 26, 2013 at 06:08:03PM +0100, Niels Thykier wrote:
>>
>> On a related note, DSA have concerns with the current arm* and mips*
>> hardware. While there have been promises of new hardware to replace
>> some of the current buggy machines, the
Am 16.01.2014 13:31, schrieb Aníbal Monsalve Salazar:
> For mips/mipsel, I - fix toolchain issues together with other developers at
> ImgTec
It is nice to see such a commitment, however in the past I didn't see any such
contributions.
Matthias
--
To UNSUBSCRIBE, email to debian-arm-requ...@l
Hi,
the gcc-4.9 in experimental fails to build while the one for armhf succeeds.
Please could somebody from the arm porters look into this?
If I remember correctly we had some issues with the arm soft float port already
with gcc-4.7 and gcc-4.8. Are the armv4t defaults still needed, or would it
gcc-4.9 is uploaded to experimental, asking the porters to watch for build
failures and corresponding patches. See
https://buildd.debian.org/status/package.php?p=gcc-4.9&suite=experimental
These are already fixed in the vcs.
- fixed the gospec.c ftbfs on archs without ld.gold
- fixed the g++ b
Am 29.10.2013 17:48, schrieb Ian Jackson:
> (Mind you, I have my doubts about a process which counts people
> promising to do work - it sets up some rather unfortunate incentives.
> I guess it's easier to judge and more prospective than a process which
> attempts to gauge whether the work has been
Am 15.06.2013 03:22, schrieb Stephan Schreiber:
> GCC-4.8 should become the default on ia64 soon; some other changes are
> desirable:
> - The transition of gcc-4.8/libgcc1 to libunwind8.
> - A removal of the libunwind7 dependency of around 4600 packages on ia64 -
> when
> they are updated next ti
Am 13.06.2013 16:46, schrieb Steven Chamberlain:
> Hi,
>
> On 13/06/13 13:51, Matthias Klose wrote:
>> GCC 4.8 is now the default on all x86 architectures, and on all ARM
>> architectures (the latter confirmed by the Debian ARM porters). I did not
>> get
>
Am 13.06.2013 21:47, schrieb Thorsten Glaser:
> Matthias Klose dixit:
>
>> The Java and D frontends now default to 4.8 on all architectures, the Go
>> frontend stays at 4.7 until 4.8 get the complete Go 1.1 support.
>
> I’d like to have gcj at 4.6 in gcc-defaults for m68k
Am 07.05.2013 15:25, schrieb Matthias Klose:
> The decision when to make GCC 4.8 the default for other architectures is
> left to the Debian port maintainers.
[...]
> Information on porting to GCC 4.8 from previous versions of GCC can be
> found in the porting guide http://gcc.gnu
It's time to change the Java default to java7, and to drop java support on
architectures with non-working java7.
Patches for the transition to Java7 should be available in the BTS, mostly
submitted by James Page. Some may be still lurking around as diffs in Ubuntu
packages, apologies for that. T
asking for some help about debian #697521 and lp: #1096619. looking at the
config.log files for armel/armhf I don't see any differences. I assume it's a
difference in the cpu configuration (armv4/v5 vs. armv7) not soft/hard-float.
any pointers?
--
To UNSUBSCRIBE, email to debian-arm-requ...@l
On 07.05.2012 19:35, Thorsten Glaser wrote:
> Matthias Klose dixit:
>
>> GCC 4.7 is now the default for x86 architectures for all frontends except
>> the D
>> frontends, including KFreeBSD and the Hurd.
>
> How are the plans for other architectures?
I don&#x
GCC 4.7 is now the default for x86 architectures for all frontends except the D
frontends, including KFreeBSD and the Hurd.
There are still some build failures which need to be addressed. Out of the ~350
bugs filed, more than the half are fixed, another quarter has patches available,
and the remai
GCC-4.7 packages are now available in testing and unstable; thanks to Lucas'
test rebuild, bug reports are now filed for these ~330 packages which fail to
build with the new version [1]. Hints how to address the vast majority of these
issues can be found at [2].
I'm planning to work on these
On 01/17/2012 10:24 AM, peter green wrote:
> While looking at armhf build failures I took a look at uwsgi I determined it
> was
> failing on armel, armhf, sh4 and powerpc due to using incorrect paths for java
> stuff (it's also failing on ia64 and alpha for what appears to be unrelated
> reasons).
On 12/30/2011 11:23 PM, Jakub Adam wrote:
>> on which platforms? i.e. are the "architecture templates" updated to build on
>> more than amd64 and i386?
>
> There are arm, ia64, mips, ppc and sparc in the additional architectures - see
> contents of
> debian/eclipse-build-additionalArchs.tar.bz2.
>
Please have a look at the gcc-4.7 package in experimental, update patches (hurd,
kfreebsd, ARM is fixed in svn), and investigate the build failures (currently
ia64, but more will appear).
Matthias
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe".
tag 644018 + moreinfo
thanks
On 10/01/2011 10:36 PM, Dmitri Gribenko wrote:
> Package: binutils-gold
> Version: 2.21.53.20110922-1
> Severity: important
>
> Hello,
>
> On armhf gold fails with internal error for objects produced from trivial
> programs.
>
> $ cat a.c
> int a;
> int b;
> $ gcc
[ CC'in debian-arm ]
On 06/21/2011 11:29 AM, Jan Flyborg wrote:
> Package: python2.7
> Version: 2.7.1-8
> Severity: important
>
> When I do 'import multiprocessing.synchronize' on my Sheevaplug with Wheezy I
> get:
>
> Traceback (most recent call last):
> File "", line 1, in
> File "/usr/l
On 04/26/2011 09:28 PM, Kurt Roeckx wrote:
On Tue, Apr 26, 2011 at 08:51:04PM +0200, Aurelien Jarno wrote:
On Tue, Apr 26, 2011 at 05:03:01PM +0200, Matthias Klose wrote:
I'll make GCC 4.6 the
default after the release of GCC 4.5.3, expected later this week, at
least on amd64, armel, i38
On 04/26/2011 05:31 PM, Konstantinos Margaritis wrote:
On 26 April 2011 18:03, Matthias Klose wrote:
I'll make GCC 4.6 the default after the release of
GCC 4.5.3, expected later this week, at least on amd64, armel, i386 and
powerpc.
Could you include armhf in the list as well?
yes, f
On 04/17/2011 09:33 PM, Adam D. Barratt wrote:
On Wed, 2011-03-02 at 02:34 +0100, Matthias Klose wrote:
I'll make gcc-4.5 the default for (at least some) architectures within the next
two weeks before more transitions start. GCC-4.5 is already used as the default
compiler for almost any
gcc-4.6 fails to build on the buildds with an ICE. Unable to reproduce on a
local armv5t machine. Please could an ARM porter reproduce this ICE and attach
the requrest information to upstream PR 48173?
https://buildd.debian.org/fetch.cgi?pkg=gcc-4.6&arch=armel&ver=4.6.0%7Erc1-2&stamp=1300694925&
On 02.03.2011 17:54, Martin Guy wrote:
> On 2 March 2011 02:34, Matthias Klose wrote:
>> armel (although optimized for a different processor)
>
> Hi
> For which processor (/architecture) is it optimized, and do you mean
> optimized-for, or only-runs-on?
> I ask
On 02.03.2011 07:36, Konstantinos Margaritis wrote:
> On 2 March 2011 03:34, Matthias Klose wrote:
>
>> I'll make gcc-4.5 the default for (at least some) architectures within the
>> next
>> two weeks before more transitions start. GCC-4.5 is already used as the
>
I'll make gcc-4.5 the default for (at least some) architectures within the next
two weeks before more transitions start. GCC-4.5 is already used as the default
compiler for almost any other distribution, so there shouldn't be many surprises
on at least the common architectures. About 50% of the b
On 18.02.2011 11:13, Guillem Jover wrote:
[ CCing Matthias, as I'd like your opinion on my proposed solution
involving some Debian gcc changes. ]
The armhf patch for gcc looks ok, however I would like to see this better
addressed in Linaro and/or upstream.
Yes but x86 goes to the other
On 16.11.2010 10:42, Roger Leigh wrote:
On Tue, Nov 16, 2010 at 01:14:09AM +0100, Matthias Klose wrote:
On 14.11.2010 13:19, Julien Cristau wrote:
On Fri, Oct 29, 2010 at 15:43:57 +0200, Matthias Klose wrote:
For wheezy I'm planning to change the linking behaviour for DSOs
(turning on
On 16.11.2010 01:24, Roger Leigh wrote:
On Mon, Nov 15, 2010 at 11:02:57PM +0100, Matthias Klose wrote:
On 14.11.2010 16:06, Roger Leigh wrote:
While I understand the rationale for --no-copy-dt-needed-entries for
preventing encapsulation violations via indirect linking, I don't agree
wit
On 14.11.2010 13:19, Julien Cristau wrote:
On Fri, Oct 29, 2010 at 15:43:57 +0200, Matthias Klose wrote:
For wheezy I'm planning to change the linking behaviour for DSOs
(turning on --as-needed and --no-copy-dt-needed-entries. The
rationale is summarized in
http://wiki.debian.org/Tool
On 14.11.2010 16:06, Roger Leigh wrote:
While I understand the rationale for --no-copy-dt-needed-entries for
preventing encapsulation violations via indirect linking, I don't agree
with the use of --as-needed *at all*. If a library has been explicitly
linked in, it shouldn't be removed. This is
On 15.11.2010 07:16, Roland McGrath wrote:
airlied_, does Fedora use --as-needed by default? Fedora 14 too?
mattst88: yes
The naming of the options makes people easily confused.
--no-add-needed is the only option Fedora's gcc passes.
yes, OpenSuse is using --as-needed, but not --no-add-ne
For wheezy I'm planning to change the linking behaviour for DSOs (turning on
--as-needed and --no-copy-dt-needed-entries. The rationale is summarized in
http://wiki.debian.org/ToolChain/DSOLinking. I would like to know about issues
with these changes on some of the Debian ports, and if we need t
On 13.10.2010 15:57, Matthias Klose wrote:
On 13.10.2010 13:31, Matthias Klose wrote:
On 13.10.2010 12:23, xavier grave wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 13/10/2010 11:46, Ludovic Brenta a écrit :
For the record, this late in the release cycle I am personally tempted
On 13.10.2010 13:31, Matthias Klose wrote:
On 13.10.2010 12:23, xavier grave wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 13/10/2010 11:46, Ludovic Brenta a écrit :
For the record, this late in the release cycle I am personally tempted to
resolve this bug by dropping support for
On 13.10.2010 12:23, xavier grave wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 13/10/2010 11:46, Ludovic Brenta a écrit :
For the record, this late in the release cycle I am personally tempted to
resolve this bug by dropping support for armel in all Ada packages. The
buildds have
On 01.09.2010 11:35, Aurelien Jarno wrote:
On Mon, Aug 30, 2010 at 06:05:15AM +0200, Aurelien Jarno wrote:
On Sun, Aug 29, 2010 at 07:30:10PM +0200, Matthias Klose wrote:
Package: libc6
Version: 2.11.2-2
Severity: grave
This change breaks OpenJDK on armel:
* Add patches/any/cvs-flush
On 06.06.2010 00:51, Aurelien Jarno wrote:
On Sat, Jun 05, 2010 at 03:50:51AM +0200, Matthias Klose wrote:
Package: eGLIBC
Version: 2.11.1-2
Severity: serious
gcc-4.4 and gcc-4.5 fail to build after the upgrade to eGLIBC-2.11:
https://buildd.debian.org/fetch.cgi?pkg=gcc-4.4;ver=4.4.4-4;arch
On 08.03.2010 13:34, Andrew John Hughes wrote:
further, is it correct that the -ecj patch is applied to *both* the openjdk
and openjdk-ecj directory?
$ ls -l build/openjdk*/jdk/src/share/classes/sun/misc/FloatConsts.java
-rw-rw-r-- 2 doko doko 4147 Feb 17 03:14
build/openjdk-ecj/jdk/src/share/cl
On 01.03.2010 20:54, Andrew John Hughes wrote:
On 27 February 2010 16:49, Matthias Klose wrote:
Building icedtea6 on alpha and armel using a two stage bootstrap fails with
different errors. These are no new errors, just rechecked the two stage
bootstrap, because the one stage build fails to
Building icedtea6 on alpha and armel using a two stage bootstrap fails with
different errors. These are no new errors, just rechecked the two stage
bootstrap, because the one stage build fails to build cacao after the b18
update. On alpha:
mkdir -p lib/rt
/home/doko/openjdk/openjdk-6-6b18~pre1
On 27.01.2010 23:11, Riku Voipio wrote:
On Wed, Jan 27, 2010 at 11:19:35PM +0200, Modestas Vainius wrote:
Hello,
On trečiadienis 27 Sausis 2010 22:47:55 Riku Voipio wrote:
There is a major problem with gcc 4.4 and armel - the ABI of va_list
changed (for c++ libraries). We need to decide one of
clone 566256 -1
reassign -1 566256
severity -1 serious
tags 566256 + wontfix
thanks
On 22.01.2010 14:56, Patrick Matthäi wrote:
Package: g++-4.4
Version: 4.4.2-9
Severity: important
std::va_list has been mangled in the 4.4 release, so some more packages FTBFS
now on armel e.g. with:
/build/buil
On 30.12.2009 01:09, Josip Rodin wrote:
On Wed, Dec 30, 2009 at 01:06:42AM +0100, Matthias Klose wrote:
- which gcc version/package was used to build this version?
https://buildd.debian.org/build.php?pkg=maildrop&arch=arm ?
I don't care to look. this information should be prov
tags 471258 + moreinfo
thanks
- which gcc version/package was used to build this version?
- is this reproducible with gcc-4.4/gcc-snapshot from unstable?
--
To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.o
Package: gobjc-4.4
Version: 4.4.1-5
Severity: important
Tags: upstream
PR41617
seen with 4.4 and 4.5 on arm-linux-gnueabi:
gcc AppController.m -c \
-MMD -MP -DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1 -DGNU_GUI_LIBRARY=1
-DGNU_RUNTIME=1 -DGNUSTEP_BASE_LIBRARY=1 -D_REENTRANT -fPIC -g -Wall
Besides the open license issue, are there any objections from port maintainers
to make GCC-4.4 the default?
As a first step that would be a change of the default for C, C++, ObjC, ObjC++
and Fortran.
I'm not sure about Java, which show some regressions compared to 4.3. Otoh it's
not amymore
On 23.08.2009 17:40, Martin Michlmayr wrote:
* Marc Brockschmidt [2009-08-16 14:40]:
How many "big" transitions will the upcoming changes cause? When should those
happen? Can we do something to make them easier?
I asked the Debian ARM list about the status and got the following
responses.
Co
Paul Brook schrieb:
>> Now it seems that the irrlicht library depends on those symbols
>> provided by libgcc_s.so.1 (and does not define them locally contrary to
>> what was seen by Aurélien in libvorbis in #462318) and of course
>> dpkg-shlibdeps complains because they can't be found in the symbol
Hi,
openjdk-6 in unstable is updated to the 6b14 code drop, built from a recent
IcedTea snapshot. There are a few regressions in the ports which don't use the
hotspot VM, but the Zero VM. Help from porters would be appreciated.
There are two new binary packages offering additional JVMs:
- openj
Package: opie
Version: 2.32-10.2
Severity: important
I packaged 2.4, based on the OpenSuse srpm, fixing the test failures
on armel. The package can be found at
https://launchpad.net/ubuntu/+source/opie/2.40~dfsg-0ubuntu1
#511570 is fixed as well.
--
To UNSUBSCRIBE, email to debian-arm-requ...@
Riku Voipio schrieb:
> Can we have a DEB_BUILD_OPTIONS=fulltests or something similar so
> we can try the full testsuite when we are at less hurry? I'll probably
> get a faster build-machine online this weekend too.
no, currently you have to edit the rules file. is this somewhere proposed as an
op
FYI
Maybe blacklist this package for the slow machines; the build already takes some
days on faster machines. the current 6b11-1 package will probably not build as
uploaded.
Matthias
--- Begin Message ---
See http://people.ubuntu.com/~doko/java/openjdk6-armel/
- the mauve test results are a su
Is this arm only, or armel as well?
Matthias
Enrico Zini writes:
> Package: g++-4.3
> Version: 4.3.1-2
> Severity: normal
>
> Hello,
>
> while trying to investigate why libept does not build on ARM, I came up
> with the attached source code. On any system, it gives a link time
> error while
is this arm only, or armel as well?
Matthias
Enrico Zini writes:
> Package: g++-4.3
> Version: 4.3.1-2
> Severity: normal
>
> Hello,
>
> the attached code seems to be the minimal test case to reproduce the
> current build failure of libept on ARM.
>
> Normally, that code should not do anythi
Did see a non-working rm for some time in coreutils, which runs in an
arm chroot, on an armel kernel. now I have a non-working findutils as
well. The machine is a n2100, running the iop32x kernel from unstable.
The last working versions of these binaries are
coreutils 5.97-5.3
findutils 4.2.3
Michael Stone writes:
> On Wed, Mar 26, 2008 at 08:35:53PM +0100, Matthias Klose wrote:
> >Did see a non-working rm for some time in coreutils, which runs in an
> >arm chroot, on an armel kernel. now I have a non-working findutils as
> >well. The machine is a n2100, running t
Besides m68k hopelessly being behind we do have serious problems on
alpha, arm and hppa.
- on arm, the bytecode compiler (ecj) doesn't produce correct code.
there is currently a workaround to build the package on arm using
byte-compiled code built on another architecture. Aurelian has
m
just remove it, or update from svn
Hector Oron writes:
> Hello,
>
> When compiling ARM gcc-4.2 i get:
>
> Hunk #1 succeeded at 6188 (offset 69 lines).
> make: *** No rule to make target
> `stamps/02-patch-stamp-libjava-armeabi', needed by
> `stamps/02-patch-stamp'. Stop.
>
tag 425343 + moreinfo
thanks
please recheck with 4.2 and 4.3/snapshot
John Reiser writes:
> Subject: [arm] gcc-4.1: bad code and no warning for thumb assembly of arm
> instruction
> Package: gcc-4.1
> Version: 4.1.1-21
> Severity: normal
>
> *** Please type your report below this line ***
> The
Andreas Barth writes:
> * Aurelien Jarno ([EMAIL PROTECTED]) [070725 23:28]:
> > Done. I have just uploaded it. For information, here is the result of
> > the testsuite:
> >
> > === libjava Summary ===
> >
> > # of expected passes2485
> > # of unexpected failures
Please try building gcj-4.2 on arm manually (using gcj-4.1 packages
from etch); all arm patches from Andrew Hailey are now integrated in
the gcj-4.2 package. Before gcc-4.2-source is installable, just
ignore the build-dependency and copy the gcc tarball from the gcc-4.2
source into the gcj-4.2 dir
1 - 100 of 123 matches
Mail list logo
