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 (
Package: src:gnumach
Version: 2:1.8+git20240406-4
Severity: important
Tags: sid trixie
User: debian-...@lists.debian.org
Usertags: ftbfs-gcc-14
[This bug is targeted to the upcoming trixie release]
Please keep this issue open in the bug tracker for the package it
was filed for. If a fix in anoth
Package: src:mig
Version: 1.8+git20231217-1
Severity: important
Tags: sid trixie
User: debian-...@lists.debian.org
Usertags: ftbfs-gcc-14
[This bug is targeted to the upcoming trixie release]
Please keep this issue open in the bug tracker for the package it
was filed for. If a fix in another pac
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
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
Package: gcc-4.9
Severity: important
Disabling libcilkrts for kfreebsd and the Hurd for now.
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52d13096.7010...@debian.or
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-hurd-requ...@
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
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
Package: hurd
Version: 1:0.5.git20140326-1
Severity: important
Tags: sid jessie
User: debian-...@lists.debian.org
Usertags: non-standard-compiler, gcc-4.7, gcc-4.7-legacy
This package builds with a non standard compiler version; please check
if this package can be built with the default version of
see https://gcc.gnu.org/ml/gcc/2013-09/msg00196.html and follow-ups. Is this
really specific for the Hurd?
Matthias
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/
Am 01.06.2014 18:28, schrieb Emilio Pozuelo Monfort:
> On 01/06/14 12:13, Sebastian Ramacher wrote:
>> On 2014-05-29 00:55:09, Scott Kitterman wrote:
>>> Source: morse-simulator
>>> Version: 1.2-2
>>> Severity: serious
>>> Justification: fails to build from source (but built successfully in the
>>
Am 04.06.2014 18:44, schrieb Ludovic Brenta:
> Hello,
>
> I see this was added without any comment in revision 7370. As a consequence,
> gcc-4.9 and gnat-4.9 both fail to build on the hurd-i386 buildd due to the
> missing build-dependency.
>
> Could you please explain why gcc must build-depend o
Am 06.07.2014 19:06, schrieb Samuel Thibault:
> Gabriele Giacone, le Sat 05 Jul 2014 03:41:09 +0200, a écrit :
>> It FTBFS on hurd
>>
>> [...]
>> cd /home/user/port/simgrid/simgrid-3.11.1/doc && /usr/bin/javadoc -quiet -d
>> /home/user/port/simgrid/simgrid-3.11.1/doc/html/javadoc/
>> /home/user/p
Am 15.07.2014 16:27, schrieb Michael Biebl:
> Source: gcc-4.9
> Version: 4.9.0-11
> Severity: serious
>
> The package FTBFS on i386 and hurd-i386 but successfully built in the
> past.
>
> Complete build log at [1]
how helpful is this report?
- i386: I'd appreciate an analysis what did go wrong
Package: src:gcc-4.9
Version: 4.9.1-1
Severity: important
User: debian-hurd@lists.debian.org
Usertags: hurd, kfreebsd
gcc-4.9 4.9.1-1 still fails to build, but test results are already available in
the build log. These don't look too good.
Please see
https://buildd.debian.org/status/fetch.php?pk
Am 20.08.2014 um 23:03 schrieb Samuel Thibault:
> Pino Toscano, le Mon 26 May 2014 08:34:47 +0200, a écrit :
>> It looks like to me there are two solutions:
>>
>> a) fix the GCC detection of threads on Hurd, so it uses only
>>pthread_key_create (or another internal symbol of Hurd's
>>libpth
Am 31.08.2014 um 03:10 schrieb Samuel Thibault:
> guess that will just fix all our issues... I'll then commit that and
> push upstream.
is this necessary for the libgc package too? (and all embedded libgc copies in
other packages)?
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.o
this looks like the same issue as for kfreebsd. help would be appreciated.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781424
thanks, Matthias
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Ar
Package: src:icu
Version: 55.1-3
Severity: important
Debian Hurd, please have a look:
simplethread.cpp:291:29: warning: unused parameter 'millis' [-Wunused-parameter]
SimpleThread::sleep(int32_t millis)
^
simplethread.cpp:349:1: error: redefinition of 'SimpleThread::
86
- Ben Hutchings
- Aurelien Jarno
- Matthias Klose
Package: hurd
Version: 1:0.8.git20160826-1
Severity: important
Tags: sid stretch
User: debian-...@lists.debian.org
Usertags: non-standard-compiler, gcc-5, gcc-5-legacy
This package builds with a non standard compiler version; please check
if this package can be built with the default version of gc
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 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 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 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
[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
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
Package: src:gcc-8
X-Debbugs-CC: debian-hurd@lists.debian.org
https://buildd.debian.org/status/fetch.php?pkg=gcc-8&arch=hurd-i386&ver=8-20171102-1&stamp=1509591656&raw=0
/<>/build/./prev-gcc/xg++ -B/<>/build/./prev-gcc/
-B/usr/i686-gnu/bin/ -nostdinc++
-B/<>/build/prev-i686-gnu/libstdc++-v3/src/.
ps://anonscm.debian.org/viewvc/gcccvs?view=revision&revision=10084
>>>>
>>>> This is really a large step BACK:
>>>
>>> It's not a step back, it's just fixing something that is completely
>>> wrong.
>>
>> What is reall
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
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
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
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
Package: src:python3.8
Version: 3.8.0~b2-4
Severity: important
The hurd-i386 and kfreebsd-* builds had some missing symbols, seen in
https://buildd.debian.org/status/fetch.php?pkg=python3.8&arch=hurd-i386&ver=3.8.0%7Eb2-1&stamp=1562346528&raw=0
https://buildd.debian.org/status/fetch.php?pkg=pytho
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
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
Forwarded ...
On 20.11.19 11:43, Fabian Kloetzl wrote:
> Package: gcc-9
> Version: 9.2.1-17
> Severity: normal
>
> Dear Maintainer,
>
> Recently, the build of one of my packages failed on hurd-i386 and
> kfreebsd-* due to unsupported ifuncs [1]. However, I had that code guarded
> by __has_attrib
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 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
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: hurd
Severity: important
User: debian-...@lists.debian.org
Usertags: non-standard-compiler, gcc-4.2
This package builds with a non standard compiler version; please check
if this package can be built with the default version of gcc/g++.
Please keep this report open until the package uses
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 20.09.2009 22:20, Samuel Thibault wrote:
Matthias Klose, le Sun 20 Sep 2009 19:58:22 +0200, a écrit :
I'm not sure about Java, which show some regressions compared to 4.3. Otoh
it's not amymore the default java compiler for all architectures except
hurd(?)
I haven't explici
Package: hurd
Version: 20090404-2
Severity: normal
User: debian-...@lists.debian.org
Usertags: non-standard-compiler, gcc-4.3
This package builds with a non standard compiler version; please check
if this package can be built with the default version of gcc/g++.
Please keep this report open until
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 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
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 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 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 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
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 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
>
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 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
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/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
A re-worked multiarch patch for gcc-4.5 is in the packaging repository,
currently lacking support for the hurd and kfreebsd. Please update the support,
as soon as possible, and check the implementation on mips*.
Basically either MULTIARCH_DIRNAME or MULTILIB_OSDIRNAMES has to be set
accordingly i
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-hurd-requ...@lists.debian.org
with a subject of "unsubscribe"
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
Hi,
I'm now planning to default to GCC 4.7 for amd64 and i386. Should kfreebsd and
the hurd do change at the same time, or should these stay with 4.6?
Matthias
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists
On 27.04.2012 14:44, Samuel Thibault wrote:
> Matthias Klose, le Fri 27 Apr 2012 14:31:16 +0200, a écrit :
>> I'm now planning to default to GCC 4.7 for amd64 and i386. Should kfreebsd
>> and
>> the hurd do change at the same time, or should these stay with 4.6?
&g
On 27.04.2012 15:03, Steven Chamberlain wrote:
> On 27/04/12 13:31, Matthias Klose wrote:
>> I'm now planning to default to GCC 4.7 for amd64 and i386. Should kfreebsd
>> and
>> the hurd do change at the same time, or should these stay with 4.6?
>
> In case
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
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
python3.3 build failure on kfreebsd and the hurd, please could somebody have a
look and propose a patch?
thanks, Matthias
--
To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.
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
Package: python3.3
Version: 3.3.2-2
Severity: important
Tags: help sid jessie
User: debian-hurd@lists.debian.org
Usertags: hurd
When running the tests, hurd has several tests disabled because they hang the
testsuite, at least on the buildds. These should be investigated, fixed and
re-enabled. See
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
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 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 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
gcc currently defines release criteria for gcc3. See
http://gcc.gnu.org/gcc-3.0/criteria.html. For ix86 Debian is proposed
as primary evaluation platform. For sparc and alpha, Ben Collins and
Chris Chimelis volunteer to evaluate gcc3. Currently we do not have
feedback from the other architectures (
Please could somebody of the Debian hurd people look at these two bug
reports for bash on the hurd?
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=71777&repeatmerged=yes
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=71778&repeatmerged=yes
Thanks
--- Begin Message ---
> Please could somebody of the Debian hurd people look at these two bug
> reports for bash on the hurd?
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=71777&repeatmerged=yes
Does a trap set on SIGINT print anything when ^C is hit? It may be
that bash is being killed b
Brian May writes:
> >>>>> "Matthias" == Matthias Klose <[EMAIL PROTECTED]> writes:
>
> Matthias> The only idea I have for a solution is to make the
> Matthias> package arch dependent. The syntax
>
> Matthias> Depends:
Jeff Bailey writes:
> The problem is the actual testsuite itself. In debian/rules2 line 311,
> they run awk against /proc/meminfo (obviously doesn't exist).
Is there a way to determine the amount of free memory (including free
swap)? Some test cases in the testsuite eat up all memory and can
c
Neal H Walfield writes:
> > Is there a way to determine the amount of free memory (including free
> > swap)?
>
> Absolutely; take a look at mach/mach.defs:vm_statistics and
> .
interesting ... is there NO way to get this information via a shell
command/script?
Neal H Walfield writes:
> On Thu, Apr 19, 2001 at 07:26:36PM +0200, Matthias Klose wrote:
> > Neal H Walfield writes:
> > > > Is there a way to determine the amount of free memory (including free
> > > > swap)?
> > >
> > > Absolutel
reassign 71777 hurd
reassign 71778 hurd
thanks
I am unable to test these. Please could someone of the hurd team check
these?
Thanks, Matthias
The current gcc-3.0 package in unstable has libffi enabled for the
Hurd. Does libffi build on the Hurd, or should libffi disabled again?
Thanks, Matthias
Good news first. It becomes more tedious to track the bug-free
packages. Besides the usual serious bugs, the following issues remain:
- wxwindows2.2 is still unbuildable in unstable, not yet removed
from unstable, package maintainer does not respond. Oh fun!
- postgresql: doesn't go to testing
Jeff Bailey writes:
> Mathias, (and an FYI cc: to Debian-hurd)
Hi Jef ;-)
> Your latest gcc-2.95 built successfully without any modifications or
> tweaks on my part. It produced:
>
> chill-2.95
> cpp-2.95
> gcc-2.95
> gobjc-2.95
> gpc-2.95
hmm, could you look, if I disabled g77-2.95 in debian/
Now that the kernel-image packages supports hw emulation of i486
instructions on i386 hardware, I'd like to change the code generation
to default to i486 (not sure if it should be tuned for any other
target, i.e. -mtune=i686).
IIRC the Hurd can be built for i586 only, so it could be used as the
de
Marcus Brinkmann writes:
> On Wed, Aug 06, 2003 at 10:05:13AM +0200, Matthias Klose wrote:
> > IIRC the Hurd can be built for i586 only, so it could be used as the
> > default target CPU as well.
>
> We only require a coprocessor, but anything < i586 doesn't make much
sorry, don't know anything about the status on the Hurd, CCing
debian-hurd.
Michael Banck writes:
> Package: gcc-3.4
> Severity: important
>
> Hello,
>
> Your package failed to build on hurd-i386:
>
> > Automatic build of gcc-3.4_3.4.3-12 on beethoven by sbuild/hurd-i386 1.170.5
> > Build start
The next gcc-* uploads, depending on the dpkg-architecture changes,
are not tested on the Hurd and on the bsd targets. So please don't
auto-build them blindly.
Matthias
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Is this a leftover, which can be changed to gcc-4.1 now?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
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 libgnatvsn4.1
The plans for the GCC 4.2 transition were described in
http://lists.debian.org/debian-devel-announce/2007/06/msg8.html
Does any port still need to stick with GCC 4.1 for a while? Feedback
from hppa, mips*, s390, powerpc, amd64, i386 porters doesn't show
objections against the transition.
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
Package: src:gcc-snapshot
Version: 1:20241216-1
X-Debbugs-CC: debian-hurd@lists.debian.org
gccrs ftbfs on hurd-amd64:
[...]
make[5]: Entering directory
'/build/reproducible-path/gcc-snapshot-20241216/build/libgrust'
Making all in libformat_parser
make[6]: Entering directory
'/build/reproducib
Package: src:gcc-snapshot
Version: 1:20241220-1
Severity: important
X-Debbugs-CC: debian-hurd@lists.debian.org
please submit patches upstream, not to the package.
[...]
/build/reproducible-path/gcc-snapshot-20241220/build/./gcc/xgcc
-B/build/reproducible-path/gcc-snapshot-20241220/build/./gcc/
the same failure is also seen on alpha, hppa, m68k, sh4.
Package: src:boost1.88
Version: 1.88.0~beta1-1~exp1
Severity: important
X-Debbugs-CC: debian-hurd@lists.debian.org
[...]
gcc.compile.c++
bin.v2/libs/process/build/gcc-14/release/x86_64/boost.process.fs-boost/debug-symbols-on/threading-multi/visibility-hidden/ext/cmd.o
"g++" -fvisibility-
Package: src:boost1.88
Version: 1.88.0~beta1-1~exp1
Severity: important
X-Debbugs-CC: debian-po...@lists.debian.org
these are seen on different architectures in the configure step on at
least alpha, hppa, m68k, sh4.
[...]
- BOOST_ARCH_WORD_BITS == 0.0.16 : no [8]
- BOOST_ARCH_WORD_BITS
Package: src:mig
Version: 1.8+git20231217-5
Severity: important
Tags: sid forky
User: debian-...@lists.debian.org
Usertags: ftbfs-gcc-15
[This bug is NOT targeted to the upcoming trixie release]
Please keep this issue open in the bug tracker for the package it
was filed for. If a fix in another
Control: severity -1 important
On 19.04.25 20:58, Jeremy Bícha wrote:
Source: openjdk-20
Version: 20.0.2+9-1
Severity: serious
X-Debbugs-CC: d...@ubuntu.com
Can we remove OpenJDK 20 from Debian now? It is only in Unstable. It
is also not included in any currently supported Ubuntu release.
OpenJ
98 matches
Mail list logo
