Randolph Chung writes:
Is that one available somewhere on an ia64 box, preferably one accessible
to John?
gcc-snapshot package, but we cannot use that to build binaries to go into the
archive (uses different library versions)
maybe if linking with static libraries is an option?
I'm not
just tried on ia64. getting only syntax errors ...
please recheck!
$ gcc-3.2 -c bug-156291.i
In file included from /usr/include/link.h:25,
from ../h/linux.h:12,
from ../h/config.h:1,
from ../h/include.h:37,
from num_log.c:27:
Package: libice-dev
Version: 4.3.0-2
Severity: serious
This is from the buildd log for ia64, building lib-gnu-awt-xlib from the
gcc-3.3 package. The static libICE.a is picked up for linking.
It works ok on ia64 with xfree86-4.2-16 and with 4.3 on i386 and hppa.
/bin/sh ./libtool --tag=CXX
This may be a compiler bug. On ia64 the package builds using gcc-3.4
from experimental. I didn't try to build 5.8.3 to see if this was
triggered by the new perl version.
Maybe it's an alternative to build miniperl with gcc-2.96 on ia64 and
gcc-2.95 on arm and m68k?
current 3.4.3 CVS has a change to add libunwind support to libgcc.
* config.gcc (ia64*-*-linux*): Always add t-libunwind to
tmake_file. Add t-libunwind-elf and ia64/t-glibc-libunwind to
tmake_file if --with-system-libunwind isn't used.
I want to reassure, that this
H. J. Lu writes:
That is a packaging issue. You should create libgcc1_3.4.3-1_ia64.deb
which depends on libunwind7.so. libunwind7.so can come from either
Mosberger's libunwind or gcc.
yes, it's a packaging issue. we currently cannot introduce new
packages to the base system for sarge.
Ian Wienand writes:
On Mon, Nov 22, 2004 at 05:30:38PM -0800, David Mosberger wrote:
That would make sense. libstdc++5 calls _Unwind_Resume() which
is/should be implemented by libunwind.so.7. With older versions of
GCC, it was implemented as part of libgcc_eh.a/libgcc_s.so.
Actually,
David Mosberger writes:
On Wed, 24 Nov 2004 00:26:01 +0100, Matthias Klose [EMAIL PROTECTED]
said:
Matthias From my point of view we can get around with it by
Matthias including the libunwind shared library in libgcc1 for the
Matthias sarge release. I'm worried about the version
David Mosberger writes:
I wanted to try this but found that the gcc-3.3 has a libgcc1 package
for hppa only. Is this intentional? I thought a new libgcc1 package
for ia64 was needed so we pick up the libunwind built from the
libunwind sources.
please get the libgcc1 package from the
David Mosberger writes:
On Mon, 13 Dec 2004 20:47:41 +0100, Matthias Klose [EMAIL PROTECTED]
said:
Matthias It's currently built by the gcc-3.4 sources and includes
Matthias the libunwind.so.7 shared library.
The libunwind.so.7 in libgcc1 v3.4.3-2 appears to be built from the
GCC
according to the changelog, nothing really has changed ... CCing to
the ia64 list.
Duraid Madina writes:
Hi Mathias, Gerhard and others,
I want to report a nasty performance regression in 3.3.5-12. Moving
from:
gcc version 3.3.5 (Debian 1:3.3.5-11)
to:
gcc version 3.3.5
gcc-4.1 uses the backport of PR 26208 from the trunk.
---BeginMessage---
Package: gcc-4.1
Version: 4.1.1-14
Severity: serious
The latest version of the glibc failed to build on ia64 with the
following error:
gcc-4.1 -nostdlib -nostartfiles -static -o
While having built and uploaded things correctly for experimental, I
didn't do the same for unstable, which now needs some manual
intervention building gnat-4.1 and gcj-4.1.
gnat-4.1 (mips mipsel s390 sparc):
- work in a sid chroot
- install gnat-4.1-base libgnat-4.1 libgnatprj4.1
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:
-
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
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
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
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/ToolChain
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
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
On 02.03.2011 07:36, Konstantinos Margaritis wrote:
On 2 March 2011 03:34, Matthias Klose d...@debian.org 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
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 other
See gcc-4.6 4.6.1-10 and PR target/50350
--
To UNSUBSCRIBE, email to debian-ia64-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e6cd425.3050...@ubuntu.com
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-ia64-requ...@lists.debian.org
with a subject of unsubscribe.
A request to recheck for ia64 build failures ([1]) wasn't answered, same with a
question wether to default GCC to 4.7 on this architecture ([2]).
I am not aware of anybody within the Debian GCC Maintainers wanting to address
the IA64 specific issues. Please step up, if you want to help with IA64
On 02.05.2012 18:07, Patrick Baggett wrote:
Matthias,
I wouldn't mind helping a bit, as I'd like to see GCC 4.7 be the default on
ia64. I'm good at C/C++ programming and can definitely provide upstream
patches, but I have absolutely no idea what the debian way of doing
things is -- right
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
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't have plans to change any other architectures
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.org/gcc-4.8
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 please,
until the 4.8 one
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 time
Control: severity -1 normal
Control: tags -1 + moreinfo help
filing this report with this severity, for a non-working non-default option
seems to be wrong.
not including the object files (including the shared objects) doesn't help,
these are missing in the upstream report as well.
--
To
Control: tags -1 + moreinfo
Afaics, the situation didn't change. There is nobody committing to work on the
toolchain for these architectures. At least for release architectures the
alternative is to drop the port unless somebody wants to maintain the toolchain
for this port. This is the current
Am 02.12.2013 23:20, schrieb Hiroyuki Yamamoto:
Hi,
I don't know whether it is appropriate that I remark,
I have no objection to moving to gcc-4.8 on ppc64, too.
this is not a question about any objections, but about a call to the ppc64
porters if they are able to maintain such a port in
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.9suite=experimental
These are already fixed in the vcs.
- fixed the gospec.c ftbfs on archs without ld.gold
- fixed the g++
Am 16.12.2013 11:34, schrieb Matthias Klose:
Package: java-common
Version: 0.50
Severity: serious
Tags: jessie, sid
openjdk-7 currently ftbfs on sparc, sparc64, s390, kfreebsd-any. So please
either remove the default-* packages on these archs, or fall back to gcj.
- the hotspot port
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
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, Matthias Klose d...@debian.org wrote:
With gcc-4.9 now available in testing, it is time to prepare for the change
of
the default to 4.9
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
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
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
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
&
[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
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
Control: tags -1 + pending
fixed in the packaging VCS
On 06.01.2018 14:09, John Paul Adrian Glaubitz wrote:
>> dh_compress: unknown option or error during option parsing; aborting
>> debian/rules:1354: recipe for target 'binary-native' failed
>> make: *** [binary-native] Error 25
>
> I'm
On 31.12.2017 15:02, John Paul Adrian Glaubitz wrote:
> Source: gcc-7
> Version: 7.2.0-18
> Severity: normal
> Tags: patch
> User: debian-ia64@lists.debian.org
> Usertags: ia64
>
> Hi!
>
> Like with gcc-6 in #885428, we need to patch src:gcc-7 to use the
> internal libunwind library when
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
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,
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
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
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
51 matches
Mail list logo
