Bug#1090824: gcc-14: still tries to use ld --package-metadata if backported to bullseye

Mon Sep 17 00:00:00 2001 From: Simon McVittie Date: Thu, 19 Dec 2024 17:05:48 + Subject: [PATCH] d/rules.patch: Don't assume bullseye binutils supports --package-metadata MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit As clarified by the c

Bug#1063767: debuginfod: should have Recommends or Depends on libarchive-tools, for bsdtar

Package: debuginfod Version: 0.188-2.1 Severity: important Control: found -1 0.190-1 By default, debuginfod wants to unpack detached debug symbols and libraries from Debian packages using bsdtar: > Feb 12 13:14:46 REDACTED docker[2367192]: [Mon Feb 12 13:14:46 2024] (7/7): > accepting archive ty

Bug#1063768: debuginfod: man page gives an outdated equivalent of -U

Package: debuginfod Version: 0.188-2.1 Severity: minor Tags: upstream Control: found -1 0.190-1 Related to the bug I recently opened regarding a missing dependency on libarchive-tools, debuginfod(8) says: -U Activate DEB/DDEB patterns in archive scanning. The default is

Bug#1053551: ftbfs on amd64 when building binary-arch

Hi, On 13.10.23 18:55, Simon Richter wrote: There are a few dependency rules in the file that seem to do the same thing, but use the wrong target name, so they are ignored, and this doesn't seem to be a complete set anyway. I'm trying with the same addition of an order-only depen

Bug#1053551: ftbfs on amd64 when building binary-arch

Hi, On 10/13/23 03:03, Simon Richter wrote: makes the problem reproducible even when building with -j2, and regardless of whether building _all packages in the same build or not. I'll check tomorrow about gcc 13 and if that also happens upstream. gcc 13 is okay, because of 0bfc50

Bug#1053551: ftbfs on amd64 when building binary-arch

Hi, On 10/12/23 19:14, Simon Richter wrote: I cannot reproduce this, and I would rather not investigate time into that. Please check if you see this with gcc-13 as well. I suspect it's a missing dependency, so the failure is more dependent on "number of threads", and that it

Bug#1053551: ftbfs on amd64 when building binary-arch

it succeeds for -b might be coincidence. I'll try adding a sleep statement to the rule generating this file and see if I can get it to reproduce always. Simon

Bug#1053519: Fix available upstream

Hi, this bug is known upstream, and a patch already exists. Would it be possible to apply this so ghdl can be compiled on arm64? Simon

Bug#1053551: ftbfs on amd64 when building binary-arch

-common.h: No such file or directory 2374 | #include "insn-attr-common.h" | ^~~~ compilation terminated. A lot of the other M2 sources are also affected. Simon -- System Information: Debian Release: 12.1 APT prefers stable-security APT policy: (50

Bug#1053519: gcc-12: ICE when compiling ghdl 3.0.0 on arm64

))) during RTL pass: cprop_hardreg Full build log is at https://buildd.debian.org/status/fetch.php?pkg=ghdl&arch=arm64&ver=3.0.0%2Bdfsg2-1&stamp=1696130520&raw=0 I have already reported this to the GCC Bugzilla. Simon - -- System Information: Debian Release: 12.1 APT pr

Bug#1028431: shows "note: the layout of aggregates containing vectors with 8-byte alignment has changed in GCC 5" with -Wno-psabi

tagged properly. Simon - -- System Information: Debian Release: 11.6 APT prefers stable APT policy: (990, 'stable'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'unstable') Architecture: ppc64el (ppc64le) Kernel: Linux 5.10.0-20-powerpc64le (

Re: Bug#992476: override: gcc-9-base:libs/optional

On Thu, 19 Aug 2021 at 00:06:00 -0500, Daniel Lewart wrote: > Please change gcc-9-base from: > libs/required > to: > libs/optional Reminder that this request for a priority reduction is still outstanding. gcc 9 has not been the default gcc since 2020, and Debian 11 was released with gcc 1

Bug#980609: missing i386-cpuinfo.h

to apply a similar patch to the official gcc package distributed in Bullseye? Having to patch the systems manually isn't optimal. Regards Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 Workaround for https://bugs.debian.org/cgi-bin/bugrepor

Bug#997826: gcc-11: Current/future gcc-N-base packages should not declare Priority: required

ntrol will need to be regenerated afterwards), but there might be subtleties that I'm missing. Thanks, smcv >From f485b1e8e618ef12056d1eea54aa4b617ec10117 Mon Sep 17 00:00:00 2001 From: Simon McVittie Date: Mon, 25 Oct 2021 14:20:16 +0100 Subject: [PATCH] d/control.m4: Make all pack

Re: Bug#993760: libexiv2-27:i386: non-baseline instructions cause crash on AMD Geode

Control: retitle -1 libexiv2-27:i386: non-baseline instructions cause SIGILL on AMD Geode Control: reassign -1 libexiv2-27 Control: affects -1 + tracker-extract Control: tags -1 + moreinfo On Mon, 06 Sep 2021 at 09:48:00 +0300, Martin-Éric Racine wrote: >Message: Process 838 (tracker-extr

Bug#972936: libgcc-s1 buster -> bullseye upgrade issues

On Sat, 13 Feb 2021 at 19:52:10 +0100, Paul Gevers wrote: > [The release team are] pretty concerned about a couple of known RC bugs > which need the proper attention of people familiar with upgrade paths > as there's potential to leave upgrading systems unbootable and/or > without a working apt. ..

Bug#981999: elfutils: please consider separating locales into elfutils-l10n or elfutils-common

Source: elfutils Version: 0.182+20210203 Severity: wishlist It seems to be easy for the locale data in libelf1 to trigger multiarch non-co-installability (#981835, etc.). This could be avoided if the locale data was in a separate Architecture: all package. The locale data is also a significant fr

Bug#981924: Bug#981930: libelf1: fails to install

On Fri, 05 Feb 2021 at 15:41:18 +, Simon McVittie wrote: > On Fri, 05 Feb 2021 at 13:11:26 +0100, Helmut Grohne wrote: > > dh-strip-nondeterminism needs to be fixed and elfutils needs to be > > binNMUed after that. > > Unfortunately, the binNMU hasn't resolve

Bug#981930: libelf1: fails to install

Control: reopen -1 On Fri, 05 Feb 2021 at 13:11:26 +0100, Helmut Grohne wrote: > dh-strip-nondeterminism needs to be fixed and elfutils needs to be > binNMUed after that. Unfortunately, the binNMU hasn't resolved this. Perhaps dh-strip-nondeterminism needs further changes, or perhaps elfutils is

Bug#981835: libelf1 violates Multi-Arch: same / unreproducible

Control: reopen -1 On Thu, 04 Feb 2021 at 13:34:09 +0100, Helmut Grohne wrote: > libelf1 is presently marked Multi-Arch: same, but coinstallation on e.g. > amd64 + mipsel fails with a file conflict: > > | Unpacking libelf1:mipsel (0.182+20210203-1) ... > | dpkg: error processing archive > /tmp/a

Re: Bug#973414: libmozjs-78-0: invalid opcodes in libmozjs when launching GDM3

Control: tags -1 + moreinfo On Fri, 30 Oct 2020 at 10:35:21 +0200, Martin-Éric Racine wrote: > [ 165.903916] traps: gnome-shell[869] trap invalid opcode ip:b5518f8a > sp:b17d6d80 error:0 in libmozjs-78.so.78.3.0[b4b98000+98c000] Which specific x86 CPU is this? I see `uname -m` is i586 rather th

Bug#972269: dwz: dbus-python FTFBS on mipsel: dwz: debian/python3-dbus-tests/usr/lib/debug/.dwz/mipsel-linux-gnu/python3-dbus-tests.debug: .debug_line reference above end of section

Package: dwz Version: 0.13-5 Severity: normal Tags: ftbfs X-Debbugs-Cc: binut...@packages.debian.org, debian-m...@lists.debian.org Control: affects -1 + src:dbus-python During the binNMUs to add Python 3.9 support, dbus-python_1.2.16-3+b1 failed to build on mipsel with binutils_2.35.1-2: dh_dw

Bug#960913: gcc-10: FTBFS with build-indep (Architecture: all only): /<>/build/./gcc/xgcc: No such file or directory

Control: severity -1 important Control: found -1 10-20200425-1 Control: retitle -1 gcc-10: intermittently FTBFS with build-indep: /<>/build/./gcc/xgcc: No such file or directory On Mon, 18 May 2020 at 11:08:36 +0200, Matthias Klose wrote: > I don't think this is an issue in the package. > > http

Bug#960913: gcc-10: FTBFS with build-indep (Architecture: all only): /<>/build/./gcc/xgcc: No such file or directory

Source: gcc-10 Version: 10.1.0-2 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) I'm not sure exactly what is going on here, but in gcc-10_10.1.0-2 building the Architecture: all packages on the buildds, the stage2 build seems to have fa

Bug#950579: libgcc1: multiple packages FTBFS on s390x: /usr/bin/ld: cannot find -lgcc_s

Package: libgcc1 Version: 1:10-20200202-1 Severity: serious Justification: FTBFS Tags: ftbfs Control: affects -1 src:glib2.0 src:xterm src:hdrmerge src:esorex https://buildd.debian.org/status/fetch.php?pkg=glib2.0&arch=s390x&ver=2.62.4-2&stamp=1580755175&file=log > Package versions: [with linebre

Bug#946285: libgcc-s1: probably needs Breaks: libgcc1 (<< 1:10)

On Fri, 06 Dec 2019 at 17:49:09 +0100, Matthias Klose wrote: > On 06.12.19 17:36, Simon McVittie wrote: > > I notice gcc-10 has switched from packaging libgcc_s.so.1 as > > "libgcc1" to the Policy-recommended name libgcc-s1. > > it's not an old version, it&

Bug#946285: libgcc-s1: probably needs Breaks: libgcc1 (<< 1:10)

Package: libgcc-s1 Version: 10-20191205-1 Severity: important I notice gcc-10 has switched from packaging libgcc_s.so.1 as "libgcc1" to the Policy-recommended name libgcc-s1. Because libgcc-s1 contains /usr/lib/MULTIARCH/libgcc_s.so.1 and libgcc1 contains /lib/MULTIARCH/libgcc_s.so.1, the new libg

Bug#931921: clutter's autopkgtests hang when ran with a libglib2.0-0 built with gcc-9

Control: reassign -1 clutter-1.0-tests Control: severity -1 serious We were trying so hard to solve this in either gcc-9 or libglib2.0-0 that we didn't consider whether it could be a clutter bug. (It is.) On Fri, 12 Jul 2019 at 11:16:53 +0100, Iain Lane wrote: > Here's the bit of code. > > >

Bug#931921: clutter's autopkgtests hang when ran with a libglib2.0-0 built with gcc-9

binary package that makes the clutter tests fail to terminate. clutter is a library that depends on glib2.0. As Iain previously noted, this is very, very far from a minimal reproducer, but it's the only one we have. > On 02.08.19 23:27, Simon McVittie wrote: > > On Fri, 02 Aug 2019 at 19

Bug#931921: clutter's autopkgtests hang when ran with a libglib2.0-0 built with gcc-9

On Fri, 02 Aug 2019 at 19:49:20 +0100, Simon McVittie wrote: > If you compile test_run_seed() with -O1, and the rest of gtestutils.c > with -O2, the clutter test hangs. Binary-searching through the extra optimizations enabled by -O2 [1] led me to the minimal change being: if you

Bug#931921: clutter's autopkgtests hang when ran with a libglib2.0-0 built with gcc-9

On Fri, 02 Aug 2019 at 11:41:05 +0100, Iain Lane wrote: > For the record: at Debconf doko suggested to me that a way to start > debugging this from the GCC end would be to produce one working and one > "broken" build of the same version of glib2.0, and then copy object > files from the broken to th

Bug#931921: clutter's autopkgtests hang when ran with a libglib2.0-0 built with gcc-9

On Fri, 12 Jul 2019 at 11:16:53 +0100, Iain Lane wrote: > I saw this on Ubuntu (9.1.0-8ubuntu1) but I've also reproduced this with > 9.1.0-8 on sid (w/gcc-defaults from experimental to use gcc-9 by > default). > > clutter's tests hang: ... > It's adding some stuff to a main loop and expecting it t

Re: Bug#907277: autoconf: AC_SEARCH_LIBS for __atomic_foo fails with AC_LANG([C++]) and g++-8

Control: retitle -1 autoconf: AC_SEARCH_LIBS for __atomic_foo fails with AC_LANG([C++]) and g++-8 On Thu, 17 Jan 2019 at 11:00:40 -0500, Nick Bowler wrote: > I'm not familiar with the library in question but the problem > appears to be specific to these __atomic_xyz builtins which seem > to get s

Re: [Pkg-utopia-maintainers] Bug#903837: dbus: SDDM with theme Breeze and KDE programs (e.g. Dolphin) take +30 seconds to start

Control: reassign 903837 libffi6 3.3~20160224-1 Control: close 903837 3.2.1-8 On Mon, 16 Jul 2018 at 01:12:01 +0200, Michael Biebl wrote: > You have an outdated version of libffi6 installed from experimental. Packages in experimental are not expected to be ready for general use (if they were read

Bug#865154: cloog-ppl: please build-depend on automake, not obsolete automake1.11

Source: cloog-ppl Version: 0.16.1-7 Severity: normal User: debian...@lists.debian.org Usertags: automake1.11 automake1.11-only This package Build-Depends on the obsolete automake1.11 package. Please check whether this package can be built correctly with the recommended automake version, as provid

Bug#861396: gcc-4.9: Compiling with -mtune=native fails on PowerMac G5 - "unrecognized argument in option -mtune=ppc970"

Package: gcc-4.9 Version: 4.9.2-10 Severity: normal Dear Maintainer, Running Debian on an old PowerMac G5, I can't use the -mtune=native switch for gcc when compiling C programs. Pick the simplest hello world code you can think of, then try: $ gcc -mtune=native test.c This will give you: cc1: e

Bug#860937: GCC major version doubled in gnatlink call

with the version gives the same error, and calling it without a version succeeds. Simon -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.

Bug#844730: gcc-6-source: gdc source is actually gzip compressed despite .xz suffix

Simon -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.8.0-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 to /bin/dash Ini

Bug#818996: Please enable -Wabi-tag warning for C++ programs

On Thu, 24 Mar 2016 at 08:57:22 -0400, Jeffrey Walton wrote: > "What a fine mess we're in" comes to mind right about now... The transition within Debian was no fun either: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=libstdc%2B%2B-cxx11;users=debian-gcc@lists.debian.org

Bug#818996: Please enable -Wabi-tag warning for C++ programs

[Removing debian-devel from Cc] On Wed, 23 Mar 2016 at 13:31:32 +0100, Matthias Klose wrote: > If you want to change that, that change should be made in dpkg-buildflags. >From the original report: > >On Tue, 22 Mar 2016 at 10:34:29 -0400, Jeffrey Walton wrote: > >>It appears Debian built the lib

Bug#818996: Please enable -Wabi-tag warning for C++ programs

Package: g++ Control: submitter -1 Jeffrey Walton On Tue, 22 Mar 2016 at 10:34:29 -0400, Jeffrey Walton wrote: > We just took a report due to > http://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html > > It appears Debian built the library with GCC, and GCC used > _GLIBCXX_USE_CXX11_A

Bug#807133: gcc-5-base: Fails to install on multiarch.

On Sat, 05 Dec 2015 at 18:51:15 -0200, felipe wrote: > Fails to build on multiarch. Sorry, but this isn't specific enough to be a useful bug report. Is this the same bug described in , with the error message "trying to overwrite shared '/

Bug#797109: libstdc++6: please consider bumping shlibs to version >= 5

On 27/08/15 21:50, Simon McVittie wrote: > On 27/08/15 21:41, Matthias Klose wrote: >> please could you name such a package and point out why it is broken? > > Sorry, no; that's second-hand information, I don't use KDE (or testing) > myself. I think https://lists.de

Bug#797109: libstdc++6: please consider bumping shlibs to version >= 5

On 27/08/15 21:41, Matthias Klose wrote: > On 08/27/2015 10:24 PM, Simon McVittie wrote: >> The libstdc++ transition would be easier to track if its shlibs forced >> a dependency on libstdc++ (>= 5) even for packages not using any of >> the new symbols. > > I

Bug#797109: libstdc++6: please consider bumping shlibs to version >= 5

Package: libstdc++6 Version: 5.2.1-15 Severity: normal The libstdc++ transition would be easier to track if its shlibs forced a dependency on libstdc++ (>= 5) even for packages not using any of the new symbols. In practice I suspect most C++ packages depend on a package that has needed a transiti

Re: Bug#790756: Packages are not [depending on libstdc++6 >= 5] after rebuild

On Tue, 25 Aug 2015 at 16:50:16 -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > And this is because the packages do not use any of the new symbols, so they > do not get the dependency on the last version. there is nothing packagers > can do about it. I wonder whether g++-5 should artificially

Bug#619719: Bug#708781: fix for non-free files in autoconf packages

On Sat, 08 Nov 2014 at 13:34:59 +, Simon McVittie wrote: > On Sat, 01 Nov 2014 at 18:55:58 -0400, Michael Gilbert wrote: > > A patch for the autoconf rc issues is available in bug #695704 for > > autoconf2.59. > > Thanks, I've made a similar change to autoconf2.64.

Bug#767699: closed by Michael Gilbert (not a problem)

On Sun, 02 Nov 2014 at 20:05:52 +0100, Bastien ROUCARIES wrote: > source include license-problem-gfdl-invariants in doc/autoconf.info (aka > invariant section and back cover) > It is not a source is missing problem. It a not modifiable problem The winning option of https://www.debian.org/vote/2006

Bug#738341: libstdc++6-4.9-dbg:i386: Import error in gdb when running libstdc++.so.6.0.20-gdb.py

ne 24 libdir = '/usr/lib/i386-linux-gnu' to libdir = '/usr/lib/debug/usr/lib/i386-linux-gnu' did the trick. Please also note that this bug is also present in at least the 4.8 variant. Cheers, Simon -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with

Bug#731886: g++-4.7: errors from valgrind for C++ program using default locale

4.8 (not tested). Simon -- System Information: Debian Release: 7.2 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11-2-amd64 (SMP w/8 CPU cores) L

Bug#677606: gcc-4.7: ICE compiling ByteToDir() from ioquake3 on any-i386

> I have been able to reduce the failing file to a self-contained file > with no #include directives, mini_q_math.c (also attached), and the > failing command-line to: > > /usr/lib/gcc/i486-linux-gnu/4.7/cc1 mini_q_math.c \ > -g -fPIC -O -fvisibility=hidden -funroll-loops -fschedule-insns2 -o - Th

Bug#639818: [SCM] GNU gnutls branch, master, updated. gnutls_3_0_4-28-ga416d28

Nikos Mavrogiannopoulos writes: > On 10/25/2011 01:25 PM, Simon Josefsson wrote: >> "Nikos Mavrogiannopoulos" writes: >> >>> use coding.c from libtasn1 git, to avoid issue when compiled with >>> gcc-4.6. >> >> Hi Nikos! What'

Bug#619719: autoconf2.64: ftbfs with dash from experimental (AC_PROG_GNU_M4 relies on echo preserving backslashes)

On Sat, 26 Mar 2011 at 08:01:26 -0500, Jonathan Nieder wrote: > Suggested fix: patch m4/m4.m4 to use $as_echo. Fixed upstream in autoconf 2.66... but this is 2.64. > Or set CONFIG_SHELL in debian/rules. Given that this outdated version of autoconf is only packaged to be able to build gcc, I thin

Bug#630417: failed sparc/powerpc build of libidn 1.22-1

Jonathan Nieder writes: > reassign 630417 libgcj-bc 1.106 > affects 630417 + gcj-4.6-jdk > found 630417 gcc-defaults/1.96 > fixed 630417 gcc-defaults/1.107 > quit > (pruning cc list) > > Hi, > > Simon Josefsson wrote: > >> Ok, so possibly #630417 does n

Bug#630417: failed sparc/powerpc build of libidn 1.22-1

Martin Alfke writes: > On Jun 20, 2011, at 4:47 PM, Simon Josefsson wrote: > >> Martin Alfke writes: >> >>>> /usr/lib/sparc-linux-gnu/gcc/sparc-linux-gnu/4.4.6/ecj1: error while >>>> loading shared libraries: libgcj_bc.so.1: cannot open shared obj

Bug#594830: failed kfreebsd-amd64 build of libidn 1.19-2

I discovered a problem that appears similar to #594830 when building Libidn on amd64-kfreebsd, see below. /Simon make[5]: Entering directory `/build/buildd-libidn_1.19-2-kfreebsd-amd64-1ln1hd/libidn-1.19/java/gnu/inet' Making all in encoding make[6]: Entering directory `/build/b

Bug#597090: libstdc++6-4.5-dev: several STL classes implicitly add to the exception specification of containing classes' destructors

Hi, actually attaching the file helps. Simon #include class interface { public: virtual ~interface(void) throw() { } }; class implementation : public interface { std::string somedata; };

Bug#597090: libstdc++6-4.5-dev: several STL classes implicitly add to the exception specification of containing classes' destructors

uctor. Simon -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYP

Re: Bug#565776: jxplorer: need libgcj10-awt package dep if running java with gcj rt

On 07/02/10 10:43 AM, Gabriele Giacone wrote: > Simon Kjika'qawej wrote: >> Severity important because it runs OK otherwise if you install it. >> This is why folks use pbuilder and such to build packages. I don't >> either, but I should ;). Anyway, installing libgcj

Bug#358924: [alpha] libmudflap testsuite killed, not reproduced in 4.3.5 and 4.4.0

20090916 (prerelease) [gcc-4_3-branch revision 151739] I don't know how gcc versus gcc-4.3/gcc-4.4 bugs are managed, so I leave the bug as is. -- Simon Paillard -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#552224: gcc-4.3: [armel] __thread variable uses R_ARM_GOTOFF32 relocation if optimizing => SEGV

Package: gcc-4.3 Version: 4.3.4-5 Severity: normal (I'm guessing that this is a compiler bug, but it could conceivably be the linker or some other toolchain component; if so, please reassign.) As described in , libcap-ng0 0.6.1 contains a _

Re: C++ symbol mangling difference between arches

's ABI changes, and the "double"/"triple" symbols are there precisely because the ABI says so. Except for a vtable/typeinfo/name group (which reeks of actual doubled code) all lines in your output are constructors, destructors and thunks to destructors. Simon -- To U

Bug#532292: java-gcj-compat-dev setup breaks pdebuild for libidn.jar

this problem should have higher severity, because others might see similar problems too. It could be a problem in how the libidn package depends on gcj, though, and suggestions on that is welcome. /Simon -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "uns

Re: Bug#504592: upgrade-reports: ok, except manual transtion from g77 to gfortran

//wiki.debian.org/GfortranTransition could be linked from the Lenny RN (but I wonder in which section of RN it would have its place). Regards. -- Simon Paillard -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: [RFC] [Cross Toolchain] Multiarch and sysrooted toolchain

at software is generally installed into "include" and "lib" dirs under a common prefix (such as most GNU software that uses the autoconf macros to find installed software). Simon -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: [RFC] [Cross Toolchain] Multiarch and sysrooted toolchain

o the search paths; since it should work with a largely unmodified snapshot of the target OS, they are pretty tolerant with the directory layout there. I don't believe that is meant as an endorsement of a particular layout, and it should work fine with --with-sysroot=/usr/ even with the current lay

Re: [RFC] [Cross Toolchain] Multiarch and sysrooted toolchain

have entirely different objectives, and there is generally no need to install anything but libraries and headers into /usr/ -- so I don't think there is a pressing need to replicate a filesystem hierarchy standard below a triplet directory. Simon -- To UNSUBSCRIBE, email to debian-gcc-re

Bug#460660: gcc-4.2-doc fails to upgrade to 4.2.2-6

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package: gcc-4.2-doc Version: 4.2.2-6 Severity: grave Justification: renders package unusable gcc-4.2-doc installs info files for gcc-4.2 and gccint-4.2 only, but its postinst calls install-info for gcc-4.2, gccint-4.2 and libgomp-4.2, causing the fol

Bug#433172: gcc-4.2: probably different issue

buntu system), but fixincludes does not link libssp. This paragraph should be taken with a grain of salt, however, as this happened in an Ubuntu Dapper chroot running on a Debian sid box, so the build might just have expected SSP support from the C library (but that may be another bug in itself).

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

--- Comment #107 from simon dot strandman at telia dot com 2007-05-28 11:49 --- (In reply to comment #106) > I haven't tried the fix in 20218. surprisingly, moving to binutils > 2.17.50.0.16.20070511 got rid of that problem. Do you know what exactly is > going on? how

Bug#363619: Spelling mistake in package description

Package: gpc Severity: minor *** diff/gpc 20c20 < The current version 2.2 (release candiate 2) implements Standard Pascal --- > The current version 2.2 (release candidate 2) implements Standard Pascal -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy

[Bug libstdc++/19664] libstdc++ headers should have pop/push of the visibility around the declarations

-- simon dot strandman at telia dot com changed: What|Removed |Added CC||simon dot strandman at telia

Penis Enlargement Patch That Works!!!

Penis Enlargement Patch That Works!!! http://www.fuxnyp.com/ss/ The more opinions you have, the less you see. The moment we choose to love we begin to move towards freedom... Education begins a gentleman, conversation completes him. I didn't really say everything I said. Noth

Cable TV Consumers Alarming Situation

universal product, it works with all digital cable boxes we have encountered so far! And we are the only ones who provide detailed instructions on ow to set everything up properly! Of course, if you don't want this anymore, just visit our page to get removed See you later, Simon Y. Emma, II [

linking with multiple versions of gcc installed

libc.so as this file is copied to the end product filesystem. Is the correct solution to use -rpath or more likely -rpath-link in my linking commands ??? If so, could some one give me some idea of the best way to use them. Many thanks, Brendan Simon.

Multiple versions of gcc installed

x27;t execute the older 2.95 compiler using the appropriate gcc switches. -V or -B. See below. Looks like there are a few installation problems for multiple versions of gcc. Regards, Brendan Simon. $ ls -l /usr/lib/gcc-lib/powerpc-linux/ total 8 drwxr-xr-x 3 root root 4096 Oct 1 16:48 2.95.4 drw

Bug#261004: gnat-3.4: gnatmake fails to build executables from ada code

Package: gnat-3.4 Version: 3.4.1-3 Severity: grave Justification: renders package unusable Try to compile a hello world. Compiling and binding works, linking fails. pslap2:scratch> gnatmake hello.adb gcc-3.4 -c hello.adb gnatbind -x hello.ali gnatlink hello.ali /usr/bin/ld: cannot find -lgnat-3.

Bug#166255: [Bug optimization/323] optimized code gives strange floating point results

PLEASE REPLY TO [EMAIL PROTECTED] ONLY, *NOT* [EMAIL PROTECTED] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323 simon dot marshall at misys dot com changed: What|Removed |Added

V I A G R A w s

Title: Buy Generic Sildenafil Citrate Online (the active ingredient in Viagra(R)) Generic Viagra . Generic Sildenafil Citrate 100mg tablets (GSC-100) and ViagraÿAE 100mg both contain 100mg of Sildenafil Citrate. The only difference is t

Bug#189983: libstdc++5: symbol __gnu_cxx::_Atomic_add_mutex missing

Package: libstdc++5 Version: 1:3.3-0pre5 Severity: normal The symbol in the subject is missing from libstdc++5. It appears to be new in gcc-3.3's libstdc++. A simple testcase like this compiled with -O2 reproduces the problem: #include int main() { std::string bleh; return 0; } g++-3.3

Bug#179298: gcj-3.2: provide "jar" command with gcj

stjar is part of the gcc package, so when creating Makefiles, I'd think I can expect to find a "jar" binary along with "gcj" or "javac"; however this is not currently true for Debian. Simon -- System Information: Debian Release: testing/unstable Architecture:

Re: Kernel 2.2.19 and gcc 2.95.2

On Wed, 18 Apr 2001, Richard Hirst wrote: > > The idea is to see whether m68k can live without gcc 2.7.2, since we seem > > to be the last platform depending on it and the maintainer wants to drop > > the package. > Oh, sorry - I missed that point. Certainly I've built and run 2.3.x and > 2.4.x