Package: gcc-11
Version: 11.2.0-4
Severity: normal
X-Debbugs-Cc: j...@joshtriplett.org
The GCC program search dirs contain many duplicated directories. Every time GCC
has to search for a file, it's doing the same searches repeatedly, and
this adds up.
$ gcc-11 -print-search-dirs | grep
that,
please consider re-enabling CET on amd64 and x32, and only disabling it
on i386.
- Josh Triplett
On Mon, May 03, 2021 at 12:56:58PM +0200, Matthias Klose wrote:
> > > Is that still the case, a few years later?
> >
> > I'm running into this issue as well. I'd like to be able to
> > cross-compile for aarch64, and I'd also like gcc -m32 to continue
> > working.
>
> yes, it's still the case.
On Mon, 21 Sep 2020 22:11:59 +0200 ni...@lysator.liu.se (Niels
=?utf-8?Q?M=C3=B6ller?=) wrote:
> Hi,
>
> in 2017, Matthias Klose marked this bug as wontfix, and explained the
> problem like this:
>
> > because the cross toolchain has /usr/include on it's include path,
> > which has
On Mon, Oct 05, 2020 at 10:22:49PM +0200, Matthias Klose wrote:
> On 10/5/20 8:35 PM, Josh Triplett wrote:
> > On Mon, Oct 05, 2020 at 12:08:28PM +0200, Matthias Klose wrote:
> >> On 10/5/20 10:39 AM, Josh Triplett wrote:
> >>> On Mon, Oct 05, 2020 at 09:32:28
On Mon, Oct 05, 2020 at 12:08:28PM +0200, Matthias Klose wrote:
> On 10/5/20 10:39 AM, Josh Triplett wrote:
> > On Mon, Oct 05, 2020 at 09:32:28AM +0200, Matthias Klose wrote:
> >> On 10/4/20 11:09 PM, Josh Triplett wrote:
> >>> libstdc++6, installed on every system
On Mon, Oct 05, 2020 at 09:32:28AM +0200, Matthias Klose wrote:
> On 10/4/20 11:09 PM, Josh Triplett wrote:
> > libstdc++6, installed on every system due to dependencies, contains
> > various Python scripts for GDB under /usr/share/gcc-10/python/ . These
> > scripts shoul
Package: libstdc++6
Version: 10.2.0-13
Severity: normal
X-Debbugs-Cc: j...@joshtriplett.org
libstdc++6, installed on every system due to dependencies, contains
various Python scripts for GDB under /usr/share/gcc-10/python/ . These
scripts should go in a dev package, not in a library package.
--
Package: gcc-8
Version: 8.2.0-15
Severity: normal
"gcc -v --help" prints some of its output to stderr, rather than stdout,
which makes it awkward to run "gcc -v --help | less" as the stderr
output steps on the pager. I think that all of the output from "gcc -v
--help" should go to stdout.
~$ gcc
.
Linking against libbacktrace seems completely fine. However, can
libbacktrace not use detached debug symbols, as found in -dbg packages?
And if so, could you move the symbols for those binaries into an
appropriate -dbg package?
- Josh Triplett
--
To UNSUBSCRIBE, email to debian-gcc-requ
.
Produced by the following code in prerm:
case $1 in
remove)
files=$(dpkg -L libstdc++6 | awk -F/ 'BEGIN {OFS=/} /\.py$/
{$NF=sprintf(__pycache__/%s.*.py[co], substr($NF,1,length($NF)-3)); print}')
rm -f $files
esac
- Josh Triplett
-- System Information:
Debian Release
suit to
compile any code which includes these architecture-specific
headers.
I've CCed the Debian GCC maintainers and multiarch developers, in the
hopes of getting some additional details that might help resolve this
problem.
- Josh Triplett
--
To UNSUBSCRIBE, email to debian-gcc-requ
On Thu, Aug 25, 2011 at 12:43:37AM +0200, Ludovic Brenta wrote:
Josh Triplett j...@joshtriplett.org writes:
When trying to use sparse on some low-level userspace code, I ran into
the following error:
/usr/include/bits/socket.h:381:11: error: unable to open 'asm/socket.h'
See http
.
- Josh Triplett
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.27-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked
== ; gcc -c test.c -o /dev/null
== USE_CONST ==
== !USE_CONST ==
test.c: In function ‘update_rocket_state’:
test.c:14: warning: ignoring return value of ‘func’, declared with attribute
warn_unused_result
- Josh Triplett and Jamey Sharp
-- System Information:
Debian Release: lenny/sid
APT prefers
Matthias Klose wrote:
Josh Triplett writes:
Package: gcc-multilib
Version: 4:4.1.2-3
Severity: wishlist
Could gcc-multilib provide an arch-gcc binary for the multilib architecture?
For instance, i486-linux-gnu-gcc on x86_64?
is there a concrete use case?
Several. First, in some cases
Package: gcc-multilib
Version: 4:4.1.2-3
Severity: wishlist
Could gcc-multilib provide an arch-gcc binary for the multilib architecture?
For instance, i486-linux-gnu-gcc on x86_64?
- Josh Triplett
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500
:
temp.c:5: warning: format ‘%d’ expects type ‘int’, but argument 2 has type
‘ptrdiff_t’
In C99, such code can use %td; the t size modifier corresponds to the
ptrdiff_t type. If the code does not want to count on c99, it could cast the
difference to a long and use %ld.
- Josh Triplett
-- System
, such as the fixincludes step, also indicate a
target of i486-pc-linux-gnu.
- Josh Triplett
signature.asc
Description: OpenPGP digital signature
use xargs --no-run-if-empty to avoid the error.
- Josh Triplett
signature.asc
Description: OpenPGP digital signature
Falk Hueffner wrote:
Josh Triplett [EMAIL PROTECTED] writes:
The sentinel attribute tells GCC to ensure that the argument list of a
variadic function always ends with a final NULL argument. It should be
possible to use this attribute for a variadic function where the
sentinel is some constant
constant other than NULL, as long as the value of the
constant can be determined at compile time and supplied as a parameter
to the sentinel attribute.
- Josh Triplett
signature.asc
Description: OpenPGP digital signature
Daniel Jacobowitz wrote:
On Fri, Oct 14, 2005 at 09:06:19AM -0700, Josh Triplett wrote:
Currently, for platforms which natively build a biarch GCC, such as
powerpc, the GCC package also attempts to build a biarch cross-compiler
when targetting that platform. This would require the installation
Daniel Jacobowitz wrote:
On Sat, Oct 15, 2005 at 07:35:39PM -0700, Josh Triplett wrote:
(such as powerpc64), because the contents are in lib64 directories and
the include files are in alternate locations as well.
The include files nowadays are in /usr/include/biarch, so no. It
would only
binary-nof-cross.mk attempts to construct a package
from files that weren't built. The attached patch fixes this problem.
- Josh Triplett
diff -Naur gcc-4.0-4.0.2.orig/debian/rules2 gcc-4.0-4.0.2/debian/rules2
--- gcc-4.0-4.0.2.orig/debian/rules2 2005-10-14 03:40:30.0 -0700
+++ gcc-4.0
a 64-bit alternate platform; it may need to be
made more sophisticated to work for 32-bit alternate platforms. I did
not include such logic, because I was not targetting a platform with a
32-bit alternate, and thus would not test that code path in my GCC
cross-compiler build.
- Josh Triplett
diff
26 matches
Mail list logo
