> Purging configuration files for libdebuginfod-common (0.185-2) ...
> /usr/bin/which: this version of `which' is deprecated; use `command -v' in
> scripts instead.
That's bad advice, for a number of reasons.
Of these, maintscripts checking for ucf is somewhat likely to run into
`command -v`
Package: libdebuginfod-common
Version: 0.185-2
Severity: wishlist
Hi!
The postrm for libdebuginfod-common doesn't have any bashisms, yet its
hashbang is #!/bin/bash. Could you please change it to #!/bin/sh?
For today, there's no gain (except for a tiny fraction of second saved
by a faster
Source: gcc-defaults
Version: 4:10.2.0-1
Severity: wishlist
Hi!
The gcc-11 package is available (mighty thanks!) but there's no
gcc/experimental counterpart for it.
Software with sane build systems can be tested using "CC=gcc-11 CXX=g++-11
CPP=cpp-11" but sanity is not as widespread as one would
Source: gcc-10-cross
Version: 10.2.0-19cross1
Severity: normal
Hi!
While trying to uninstall cross toolchain:
WARNING: The following essential packages will be removed.
This should NOT be done unless you know exactly what you are doing!
libgcc-s1-arm64-cross gcc-10-cross-base (due to
Package: gcc-snapshot
Version: 1:20190102-1
Severity: normal
Hi!
While "c++-compiler" is conspicuously missing from Policy's list of virtual
packages, it is natural to assume any such package declares an alternative
for /usr/bin/c++ -- otherwise, without a common interface, the virtual
package
Control: reassign -1 gcc-8
Control: reopen -1
Still reproducible, with gcc-8.
It should either return an error, or fall back to some musl thing.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands
⢿⡄⠘⠷⠚⠋⠀ for Privacy.
⠈⠳⣄
[Oy vey, crosspost list from hell -- not sure how to trim...]
On Tue, Dec 11, 2018 at 09:46:21PM +0100, Gregor Riepl wrote:
> I do think this just reinforces the point that second-class architectures
> should have better, more robust support from the Debian project.
> For example, arch-specific
> gcc-doc-defaults FTBFS since GCC-7 was made the default compiler:
Which raises a question: where's gcc-7-doc?
--
⢀⣴⠾⠻⢶⣦⠀ What Would Jesus Do, MUD/MMORPG edition:
⣾⠁⢰⠒⠀⣿⡁ • multiplay with an admin char to benefit your mortal
⢿⡄⠘⠷⠚⠋⠀ • abuse item cloning bugs (the five fishes + two breads
Control: retitle -1 Should update to gcc-6-doc packages
Now that the compiler itself defaults to gcc-6, the docs should follow suit.
--
An imaginary friend squared is a real enemy.
On Tue, Jul 05, 2016 at 08:31:24AM +0200, Mathieu Malaterre wrote:
> I cannot see the builtin mentionned anywhere other than on the X86 page:
>
> X86 (ok):
> https://gcc.gnu.org/onlinedocs/gcc-6.1.0/gcc/x86-Built-in-Functions.html#index-g_t_005f_005fbuiltin_005fcpu_005finit-4335
>
> PowerPC
Package: gcc-6
Version: 6.1.1-6
Severity: normal
Hi!
According to the documentation: (gcc-6.info.gz)PowerPC Built-in Functions
__builtin_cpu_supports() can be used for detection of a number of CPU
features, such as altivec. This is same as that function on x86, other
than understandably a
Package: gcc-6
Version: 6.1.1-1
Severity: wishlist
Hi!
Upstream added a new option, -mmusl that's supposed to use musl instead of
glibc.
However, our current build in Debian instead silently almost ignores it
("almost"
as it has a small but unsufficient effect):
[/tmp]$ gcc-6 -Wall -mmusl
It doesn't seem to work for non-cross builds either.
>From upstream changelog:
# * Support for the musl C library was added for the AArch64, ARM,
# MicroBlaze, MIPS, MIPS64, PowerPC, PowerPC64, SH, i386, x32 and x86_64
# targets. It can be selected using the new -mmusl option in case musl is
Hi!
If you'd switch gcc-doc to gcc-5-doc, it would allow dropping gcc-4.9-doc.
--
A tit a day keeps the vet away.
Package: src:gcc-defaults
Version: 1.128
Severity: wishlist
x32 suffered a long outage of its buildd, but Daniel Schepler has since
fixed it and gcc-4.9 is now available for x32 as well. Thus, its defaults
can be brought in line with the rest of architectures.
It hasn't seen any testing yet,
Package: gcc-doc
Version: 5:4
Severity: normal
Description-en: documentation for the GNU compilers (gcc, gobjc, g++)
This is the dependency package that should install manual pages
and documentation for Debian default version of GNU compilers.
yet:
Depends: gcc-4.7-doc (= 4.7.2-1)
rather than
Package: gcc-4.7
Version: 4.7.0-11
Severity: normal
Hi!
Building a cross-compiler fails with:
.-
The directory that should contain system headers does not exist:
/usr/arm-linux-gnueabi/include
`-
And here's the cause:
[~]$ dpkg -L libc6-dev:armel|grep arm-linux-gnueabi|head -n1
Hi!
It looks like version 4.7.0-8 of g++-4.7 includes a fix for this one.
On the other hand, gcc-snapshot 20120501-1 is still broken. It's likely
the ICE has been already fixed upstream, though.
Is there a trivial way to uupdate -snapshot? If not, I guess it's best to
wait until you make your
On Mon, Apr 16, 2012 at 11:50:44AM +0200, Matthias Klose wrote:
I tried following the upstream docs on how to debug or reduce LTO problems,
but it turns out this is currently beyond me, thus I'm sadly reporting
without a minimal testcase.
as document on
Package: g++-4.7
Version: 4.7.0-2
Severity: normal
When building Crawl with gcc-4.7 or gcc-snapshot, I get:
In file included from :7797:0:
/usr/include/c++/4.7/bits/stl_tree.h: In function
Package: src:gcc-4.6
Version: 4.6.0-14
Severity: normal
Hi!
When building a cross compiler, there are two problems:
1. hardcoded use of gcc-4.4 without a declared build-dependency. This could
be fixed by adding the latter, however I see that it not only builds
correctly with gcc-4.6, but also
Hi,
I just tried it with g++-4.5, same ICE.
Should I report it against that version as well?
--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.
--
To
Package: gcc-snapshot
Version: 20070613-1
Severity: wishlist
README.Debian says:
.-
| You might also like to use a shell script to wrap up this
| funcationality, e.g.
|
| place in /usr/local/bin/gcc-snapshot and chmod +x it
|
| --- snip --
| #! /bin/sh
|
23 matches
Mail list logo
