Bug#1073830: gcc-14: Missing build dependency on cargo on hurd-i386

working. And conversely, rust was actually ported to hurd, so we can enable rs on it. The attached patch achieves both. Samuel diff --git a/debian/control b/debian/control index 3ae16fd6..a7e40296 100644 --- a/debian/control +++ b/debian/control @@ -15,7 +15,7 @@ Build-Depends: debhelper (>= 11), dpkg-

Bug#1066932: gcc-14: Please enable m2 on hurd-any

Source: gcc-14 Version: 14-20240303-1 Severity: normal Tags: patch User: debian-h...@lists.debian.org Usertags: hurd Hello, Now that upstream has fixed the m2 portability (available in the 20240303 snapshot), could you enable m2 on hurd-any, as the attached patch does? Thanks, Samuel -- System

Bug#1063643: gcc-14: Fix disabling go and m2 according to OS

Samuel Thibault, le sam. 10 févr. 2024 13:07:44 +0100, a ecrit: > There was a typo in rules.defs concerning go_no_systems and > m2_no_systems: they are still compared against DEB_TARGET_ARCH_OS, > while their content is gnu-system-like (kfreebsd-gnu, gnu), and > indeed all other fo

Bug#1063643: gcc-14: Fix disabling go and m2 according to OS

(kfreebsd-gnu, gnu), and indeed all other foo_no_systems variables are compared against DEB_TARGET_GNU_SYSTEM. This was making the hurd-i386 build get stuck while building m2, the attached patch fixes it. Samuel -- System Information: Debian Release: trixie/sid APT prefers testing APT policy

Bug#1063642: gcc-13: Fix disabling go and m2 according to OS

(kfreebsd-gnu, gnu), and indeed all other foo_no_systems variables are compared against DEB_TARGET_GNU_SYSTEM. This was making the hurd-i386 build get stuck while building m2, the attached patch fixes it. Samuel -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990

Bug#1057004: gcc-13: hurd-amd64 support

commits, which will thus be included in gcc 14. The parts in hurd-multiarch.diff and hurd-multilib-multiarch.diff are for long term, like gcc-multiarch.diff and gcc-multilib-multiarch.diff for other archs. Thanks, Samuel -- System Information: Debian Release: trixie/sid APT prefers testing APT

Bug#1040071: libelf-dev: Missing dep from libelf-dev to libzstd-dev

Package libzstd was not found in the pkg-config search path. Perhaps you should add the directory containing `libzstd.pc' to the PKG_CONFIG_PATH environment variable Package 'libzstd', required by 'libelf', not found thus breaking various packages that use libelf, e.g. gl

Bug#1035614: gcc-13: hurd-amd64 support

Package: gcc-13 Version: 13.1.0-1 Severity: important Tags: patch Hello, We're starting the hurd-amd64 port :) Here is a patch to add support to the gcc package (here against the master branch). Samuel -- System Information: Debian Release: 12.0 APT prefers testing APT policy:

Re: Bug#970614: gcc-10: Please disable systemtap-sdt-dev build-dep on non-Linux

Svante Signell, le sam. 19 sept. 2020 22:51:10 +0200, a ecrit: > On Sat, 2020-09-19 at 22:05 +0200, Samuel Thibault wrote: > > systemtap is a Linux thing, and doesn't currently build on non-Linux > > ports, could you disable the dependency as the attached patch does? >

Bug#970614: gcc-10: Please disable systemtap-sdt-dev build-dep on non-Linux

Package: gcc-10 Version: 10.2.0-7 Severity: important Tags: patch Hello, systemtap is a Linux thing, and doesn't currently build on non-Linux ports, could you disable the dependency as the attached patch does? Thanks, Samuel -- System Information: Debian Release: bullseye/sid APT pr

Bug#960928: gcc-9: Do not pass --with-arch=i586 on hurd-i386.

Matthias Klose, le lun. 18 mai 2020 16:43:06 +0200, a ecrit: > the kfreebsd bits are configured explicitly as well. You mean CONFARGS += --with-arch-32=i686 is not only for the 32bit-target-built-in-64bit-host? Then ok, and sorry for the noise. Samuel

Bug#960928: gcc-9: Do not pass --with-arch=i586 on hurd-i386.

te us sooner or later. We don't want to make the hurd-i386 toolchain use special cases compared to linux and kfreebsd, just let it use the same way as linux-i386 and kfreebsd-i386. Samuel

Bug#960928: gcc-9: Do not pass --with-arch=i586 on hurd-i386.

Matthias Klose, le lun. 18 mai 2020 15:49:40 +0200, a ecrit: > On 5/18/20 3:28 PM, Samuel Thibault wrote: > > Matthias Klose, le lun. 18 mai 2020 15:25:41 +0200, a ecrit: > >> On 5/18/20 2:59 PM, Samuel Thibault wrote: > >>> It seems hurd-i386 was left with buildin

Bug#960928: gcc-9: Do not pass --with-arch=i586 on hurd-i386.

Matthias Klose, le lun. 18 mai 2020 15:25:41 +0200, a ecrit: > On 5/18/20 2:59 PM, Samuel Thibault wrote: > > It seems hurd-i386 was left with building with --with-arch=i586, while > > there is no reason any more to do so. I checked building glibc, hurd, > > gnumach, without

Bug#960928: gcc-9: Do not pass --with-arch=i586 on hurd-i386.

well, the same patch will work, I'll clone+reassign the bug. Samuel -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500

Bug#945133: gcc-9: __has_attribute(ifunc) false positive on hurd and kfreebsd

not really useful here, but I'm not the one to be convinced :) I'd say bring the issue to upstream gcc. Samuel

Re: GCC | Disable gm2 on hurd-i386, mc hangs there (!3)

Gaius Mulley, le mar. 17 sept. 2019 20:28:18 +0100, a ecrit: > I'll download a i386 hurd iso image and see if I can reproduce the 'mc' > hang, I'd say better go with a preinstalled VM image. Samuel

Re: GCC | Disable gm2 on hurd-i386, mc hangs there (!3)

roject features, permission", there is a "Merge requests" part in which you can restrain merge requests to project members. That should reduce a lot the risk for such kind of merge requests. Samuel

Bug#940600: gcc-9: Please disable gm2 on hurd-i386 too

Package: gcc-9 Version: 9.2.1-4 Severity: important Tags: patch Hello, mc hangs on hurd-i386, could you disable m2 there as the attached patch does? Samuel -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstabl

Bug#894080: gcc-8: FTBFS on hurd-i386

Control: tags -1 + pending Hello, Svante Signell, le lun. 26 mars 2018 11:55:17 +0200, a ecrit: > Attached are patches to enable gccgo to build properly on Debian > GNU/Hurd on gcc-8 (8-8-20180321-1 and earlier). Fixed and applied, thanks! Samuel

Bug#893676: hurd: internal compiler error building petsc

Drew Parsons, on mer. 21 mars 2018 19:25:21 +0800, wrote: > On Wed, 2018-03-21 at 09:19 +0100, Samuel Thibault wrote: > > Drew Parsons, on mer. 21 mars 2018 12:44:03 +0800, wrote: > > > The build of PETSc 3.8 triggers an internal compiler error on hurd: > > > > >

Bug#893676: hurd: internal compiler error building petsc

((mpfr_prec_t)((mpfr_uprec_t)(~(mpfr_uprec_t)0)>>1)) > /<>/petsc-3.8.3+dfsg1/src/vec/vec/interface/vector.c: In function > 'VecSetInf': > /<>/petsc-3.8.3+dfsg1/src/vec/vec/interface/vector.c:1860:1: > internal compiler error: Aborted >} Well, perhaps it's just because the current version of gcc-7 isn't built. Samuel

Re: Update: Hurd port for gcc-7 go : 7.3.0-8+ for glibc 2.26+

bian, thanks! Samuel

Bug#885056: gcc-7: Please enable PIE on hurd-i386

. Samuel -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 'stable-debug'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 'unstable'

Re: Hurd port for gcc-7 go PATCH 1-3(15)

libc-2.24. FI, this was uploaded. > Adding to this, the executable ./build/gotools/go does work displaying the > help > text, but e.g. ./build/gotools/go env exits with a SIGILL: Illegal > instruction. That seems to be still happening with the updated libc. Samuel

Re: nvidia-cuda-toolkit: nvcc needs to pass -fpie to compiler

to compiler arguments, reference: [1] > > [1] http://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html That's probably a reasonable thing to do on that side, yes. Samuel

Re: nvidia-cuda-toolkit: nvcc needs to pass -fpie to compiler

r hand, for instance, cuda application package > "caffe-contrib" was thoroughly > and finely compiled by clang-3.8 . Sure, but application Makefiles are not ready for that, we had to tinker them to use clang-3.8, and NEWS.Debian.gz only talks about the invokation of nvcc, not the eventual linking issue. Samuel

Re: Bug#861878: nvidia-cuda-toolkit: nvcc needs to pass -fpie to compiler

Samuel Thibault, on ven. 05 mai 2017 11:59:19 +0200, wrote: > Now that gcc has defaulted to building with pie, we're getting issues > with the binaries produced by nvcc: > > cc-c -o test.o test.c > nvcc -ccbin clang-3.8 -c test-cuda.cu -o test-cuda.o > cc test.o t

Bug#861878: nvidia-cuda-toolkit: nvcc needs to pass -fpie to compiler

#x27;d tend to think /usr/bin/nvcc should actually do exec /usr/lib/nvidia-cuda-toolkit/bin/nvcc --compiler-options -fpie "$@" to save users big headaches. Samuel -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (990, 'testing'), (500, 'un

Re: Hurd port for gcc go PATCH 1-4(23)

Samuel Thibault, on Mon 19 Dec 2016 00:25:35 +0100, wrote: > as the attached patch does, which should really be applied or done > any other way. Or rather this patch, which makes it more like the test above. Matthias, I'm committing this to Debian's gcc-6, along the other go pat

Re: Hurd port for gcc go PATCH 1-4(23)

en less implemented. So here it'd be "just" a matter of implementing /proc/self/exe. Samuel Index: runtime/go-caller.c === --- runtime/go-caller.c (révision 235086) +++ runtime/go-caller.c (copie de travail) @@ -93,7 +93,

Re: Hurd port for gcc go PATCH 1-4(23)

Svante Signell, on Wed 07 Dec 2016 15:32:31 +0100, wrote: > On Wed, 2016-12-07 at 15:08 +0100, Samuel Thibault wrote: > > Ok, but then I'd say move the function which change to a separate file, > > so that the other functions are kept shared. > > Otherwise it'll b

Re: Hurd port for gcc go PATCH 1-4(23)

hich change to a separate file, so that the other functions are kept shared. Otherwise it'll be tedious to maintain. Samuel

Re: Hurd port for gcc go PATCH 1-4(23)

Svante Signell, on Sun 27 Nov 2016 18:17:17 +0100, wrote: > On Sun, 2016-11-27 at 18:02 +0100, Samuel Thibault wrote: > > > But as you wish, an updated patch is attached. > > > >  _Bool > >  Continued (uint32_t *w) > >  { > > +#ifndef WCONTINUED

Re: Hurd port for gcc go PATCH 1-4(23)

0-9]*\) .*$/\1/'` > > > + if test "$goos" = "gnu"; then > > > + sleeppid=`ps -o pid,ppid | grep " > > > $alarmpid " | grep sleep | sed -e 's/ *\([0-9]*\) .*$/\1/'` > > > + else > > > + sleeppid=`ps -o pid,ppid,comm | grep " > > > $alarmpid " | grep sleep | sed -e 's/ *\([0-9]*\) .*$/\1/'` > > > + fi > > >   kill $alarmpid > > >   wait $alarmpid > > >   if test "$sleeppid" != ""; then > > > > > > We could rather just implement the comm field in ps, AIUI it's just > > an > > alias for the command field. > > Your choice. When implemented this patch wouldn't bee needed. Then please do implement it :) Samuel

Re: Hurd port for gcc go PATCH 1-4(23)

status=$? > if ! test -f gotest-timeout; then > - sleeppid=`ps -o pid,ppid,comm | grep " $alarmpid " | grep > sleep | sed -e 's/ *\([0-9]*\) .*$/\1/'` > + if test "$goos" = "gnu"; then > + sleeppid=`ps -o pid,ppid | grep " $alarmpid " | grep > sleep | sed -e 's/ *\([0-9]*\) .*$/\1/'` > + else > + sleeppid=`ps -o pid,ppid,comm | grep " $alarmpid " | > grep sleep | sed -e 's/ *\([0-9]*\) .*$/\1/'` > + fi > kill $alarmpid > wait $alarmpid > if test "$sleeppid" != ""; then We could rather just implement the comm field in ps, AIUI it's just an alias for the command field. Samuel

Bug#783876: Seriously, these binaries should be stripped by default

ldds install extra packages & such is not very difficult. It's a matter of changing the sbuild behavior for buildd chroots. Samuel

Bug#815967: gcc-5: Updated ada-hurd.diff

Hello, Svante Signell, on Fri 26 Feb 2016 08:00:44 +0100, wrote: > This patch also applies to gcc-6, so a separate bug report will be submitted > to > the latest version in experimental. It indeed applies well on gcc-6 too. I have commited the update to both gcc-5 and gcc-6. Thanks, Samuel

Re: gcc-5 fails to build on hurd-i386

Control: tags -1 + patch Hello, Samuel Thibault, le Tue 07 Apr 2015 00:05:01 +0200, a écrit : > Matthias Klose, le Sun 29 Mar 2015 21:44:37 +0200, a écrit : > > this looks like the same issue as for kfreebsd. help would be appreciated. > > > > https://bugs.debian.org/cgi-

Re: gcc-5 fails to build on hurd-i386

ace from Linux, as can be read in the attached patch. Samuel Index: debian/patches/ada-hurd.diff === --- debian/patches/ada-hurd.diff(révision 7956) +++ debian/patches/ada-hurd.diff(copie de travail

Bug#778440: libgcc-5-dev: hardcorded omp_nest_lock_t size breaks non-linux use

N_32@))); #elif defined(mx32) unsigned char _x[@OMP_NEST_LOCK_SIZE_x32@] __attribute__((__aligned__(@OMP_NEST_LOCK_ALIGN_x32@))); #elif defined(m64) unsigned char _x[@OMP_NEST_LOCK_SIZE_64@] __attribute__((__aligned__(@OMP_NEST_LOCK_ALIGN_64@))); #endif the _32, _x

Bug#755295: gcc testsuite on hurd-i386

Samuel Thibault, le Mon 09 Feb 2015 19:17:14 +0100, a écrit : > # of unexpected failures124 > > To be compared with i386: > > # of unexpected failures94 > > The difference is essentially [...] some cleanup-*.c failures Those and a lot others later in the

Bug#755295: Hurd term server (was: Hurd GCC ping)

Samuel Thibault, le Mon 09 Feb 2015 18:08:43 +0100, a écrit : > Samuel Thibault, le Mon 09 Feb 2015 18:03:33 +0100, a écrit : > > by comparing the first test passes, I can confirm that there are *WAY* > > fewer failures with this workaround in place. > > And the few dozen fa

Bug#755295: Hurd term server (was: Hurd GCC ping)

Samuel Thibault, le Mon 09 Feb 2015 18:03:33 +0100, a écrit : > by comparing the first test passes, I can confirm that there are *WAY* > fewer failures with this workaround in place. And the few dozen failures I have seen so far also happen with the i386 build. Samuel -- To UNSUBSCRIBE,

Bug#755295: Hurd term server (was: Hurd GCC ping)

comparing the first test passes, I can confirm that there are *WAY* fewer failures with this workaround in place. So these were really due to expect/tcl bad buffering. Samuel -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe&q

Bug#755295: Hurd term server (was: Hurd GCC ping)

, 1024) = 1024 read(6, "ix \"fdd\" on floating constant\r\n/"..., 1024) = 1024 read(6, 0xdd6568, 1024) = -1 EIO (Input/output error) and the output is truncated to only the 2 first series of writes! I guess the fix should be in tcl, to store the error, and pr

Bug#755295: Hurd term server (was: Hurd GCC ping)

I don't see why it should be done in packet mode only. The qsize check, on the other hand, makes sense to me, we should keep it. Samuel -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150118193829.gj2...@type.youpi.perso.aquilenet.fr

Bug#755295: Hurd term server (was: Hurd GCC ping)

< /tmp/d" > #spawn printf "%4095d\r\nabc" 1 > #spawn printf "%4096d%4096d\r\nabc" 1 2 > interact I don't manage to make this behave differently on Linux and on GNU/Hurd. Which testcase should I be enabling above? What is supposed to be

Bug#755295: Hurd term server (was: Hurd GCC ping)

t;, »screen > Logout Hang«. Does the patch below fix the expect issue? Samuel diff --git a/term/ptyio.c b/term/ptyio.c index 211e70a..6b01585 100644 --- a/term/ptyio.c +++ b/term/ptyio.c @@ -331,7 +331,7 @@ pty_io_read (struct trivfs_protid *cred, } } - if (!(termflags &

Bug#753791: Java failures in packs on hurd-i386... [Bug#753791: simgrid: FTBFS on hurd-i386]

Matthias Klose, le Sun 31 Aug 2014 18:39:21 +0200, a écrit : > 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 embedd

Bug#753791: Java failures in packs on hurd-i386... [Bug#753791: simgrid: FTBFS on hurd-i386]

Control: clone -1 -2 Control: reassign -2 libc0.3 There was also another issue, which was basically making boehm-gc completely ignore pointers on the main stack. This was in libc0.3, thus cloning & reassigning. Samuel -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org wi

Bug#753791: Java failures in packs on hurd-i386... [Bug#753791: simgrid: FTBFS on hurd-i386]

ehm-gc was made to use mmap on kfreebsd too, not only Linux. I've just started a gcc build with using mmap on hurd too, I guess that will just fix all our issues... I'll then commit that and push upstream. Samuel -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a sub

Bug#749290: g++-4.8: broken std::thread on Hurd

d by this, glibc's testsuite log goes without a fuss). I haven't seen any other mail from Thomas, let alone about the std::thread issue at stake here. Samuel -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listm

Bug#749290: g++-4.8: broken std::thread on Hurd

build failure we've seen recently. I have updated the fixed libpthread on http://people.debian.org/~sthibault/tmp/libpthread-2.19.so (which thus now contains both the thousands-thread fix and std::thread fix). Samuel -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org w

Bug#753791: simgrid: FTBFS on hurd-i386

3] $108 = 0x14 (gdb) p/x ((unsigned long*) 0x80af964)[14] $109 = 0xe (gdb) p/x ((unsigned long*) 0x80af964)[15] $110 = 0xe9707512 Most values are proper pointers, except 0 of course, and 0x14, 0xe, 0xe9707512. I don't know how this dispatch table gets filled, and whether 15 is a sane value for it,

Bug#751532: Bug#750811: brltty: FTBFS on kfreebsd*

rr, the latest gcj now happens to have jni_md.h next to jni.h, and thus brltty builds again... Samuel -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140717214542.gw6...@type.youpi.perso.aquilenet.fr

Bug#754879: FTBFS on i386

rd porters have a look? It didn't break. We are just having a bug between strip and fakeroot-tcp, possibly a race in the latter. I didn't get the time to rerun it through fakeroot-hurd yet. I've now scheduled it. Samuel -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debi

Bug#753604: Bug#753791: simgrid: FTBFS on hurd-i386

tony mancill, le Tue 08 Jul 2014 22:20:01 -0700, a écrit : > Program received signal SIGUSR1, User defined signal 1. SIGUSR1 is benign. Please use handle USR1 nostop noprint pass To let gdb continue the program, up to where there actually is an illegal instruction. Samuel -- To UNSUBSCR

Bug#753791: simgrid: FTBFS on hurd-i386

11.1/src/bindings/java/org/simgrid/*.java > /home/user/port/simgrid/simgrid-3.11.1/src/bindings/java/org/simgrid/*/*.java > Segmentation fault (core dumped) Well, we have been seeing gcj-4.9 crashes in various packages recently. I don't think it's up to simgrid maintainers to look f

Bug#751532: Bug#750811: Bug#751532: Bug#750811: brltty: FTBFS on kfreebsd*

Matthias Klose, le Mon 23 Jun 2014 16:12:11 +0200, a écrit : > Am 23.06.2014 16:05, schrieb Samuel Thibault: > > Matthias Klose, le Mon 23 Jun 2014 15:50:49 +0200, a écrit : > >> so for now packages building jni bindings should have both > >> /include > >> an

Bug#751532: Bug#750811: Bug#751532: Bug#750811: brltty: FTBFS on kfreebsd*

uld it really also include include/linux, even if it doesn't even directly include anything from it? Samuel -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.o

Re: Why does gcc-4.9 suddenly build-depend on gdb?

build against the newer mig. I thought somebody was working on it, but apparently it's not there yet. I can probably build the newer version of gdb by hand against the old mig. Samuel -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe&quo

Bug#748317: closed by Matthias Klose (Re: Bug#748317: libstdc++6: Pretty-printers don't support Python 3)

Control: notfixed -1 4.9.0-3 Control: reopen -1 Sorry, I forgot to include a demo in my report. I really do have the latest sid version of libstdc++6 installed, and this *still* happens: naesten@hydrogen:~/hacking% sudo apt-get install libstdc++6/sid Reading package lists... Done Building depend

Bug#748317: libstdc++6: Pretty-printers don't support Python 3

Package: libstdc++6 Version: 4.9.0-3 Severity: important Control: affects -1 gdb Dear doko, On May 6, you NMU'd gdb to make it build against Python 3. Which would be all well and good, except for one thing: the pretty-printers for libstdc++ are *still* using Python 2 syntax. (Any particular reas

Bug#748315: libgcc1: GDB could use SystemTap SDT probes

Package: libgcc1 Version: 1:4.7.2-5 Severity: normal Control: affects -1 gdb Dear Maintainer, GDB (since version 7.5) could take advantage of SystemTap probes in libgcc/libstc++ to allow "next" and the like to work properly when exceptions are thrown, even without the debugging symbols installed.

Bug#748024: gcc-4.9-plugin-dev: gcc plugins can not build

-o test -I$(g++-4.9 -print-file-name=plugin)/include ... /usr/lib/gcc/x86_64-linux-gnu/4.9/plugin/include/gimple.h:276:22: error: field ‘call_used’ has incomplete type ‘pt_solution’ struct pt_solution call_used; struct pt_solution is nowhere to be found in the plugin headers. Samuel -- System

Bug#701935: /usr/lib/debug/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.18-gdb.py: Re: libstdc++6-4.7-dbg: Pretty-printers appear not to load (but do)

I found another patch for the part where the pretty-printers won't load at all, starting at : Index: b/src/libstdc++-v3/python/hook.in === --- a/src/

Bug#718514: gcc-doc: "info gcc" opens the manpage unreadably

Package: gcc-doc Version: 5:4 Severity: normal Dear Maintainer, When I type "info gcc", rather than the GCC manual, I get a (really bad) rendition of the gccgo manpage. It seems that the symlink "/usr/share/info/gcc.info.gz -> gcc-4.7.info.gz" is insufficient, probably because it still says this

Bug#701941: libstdc++6: Debug symbols should be in libstc++6-dbg

Okay, here's a patch against 4.8.1-4 that seems to work to split out the debug symbols. I'm not sure why you want this, though: it doesn't seem terribly important to be able to install a debug version of libstdc++ that from a different gcc-X.Y, and it makes the packaging just that much messier ..

Bug#701941: libstdc++6: Debug symbols should be in libstc++6-dbg

Huh. I never even noticed that other library was in there. What's it for, and where's it documented? (And why in the world is there a static version of it?) -- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists

Bug#714559: gcj-4.8-jdk: jni_md.h not found

to do: disable Java extensions on such platforms (because jni_md.h perhaps doesn't work on kfreebsd?), or is there a standard way to get jni.h working? Samuel -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'

Bug#701941: libstdc++6: Debug symbols should be in libstc++6-dbg

Control: tags -1 + patch This patch seems to be sufficient to fix the issue in gcc-4.8; it should be fairly clear how to do the same for the others: pgpmsVXW698QF.pgp Description: PGP signature diff -u gcc-4.8-4.8.1/debian/control.m4 gcc-4.8-4.8.1/debian/control.m4 --- gcc-4.8-4.8.1/debian/cont

Bug#701941: libstdc++6: Debug symbols should be in libstc++6-dbg

Package: libstdc++6 Version: 4.7.2-5 Severity: normal Dear Maintainer, The debug symbols for this package should really be in a package named libstdc++6-dbg, not a different libstdc++6-X.Y-dbg package for every gcc-X.Y source package. The status quo makes the symbols hard to install, hard to upg

Bug#701935: libstdc++6-4.7-dbg: Pretty-printers appear not to load (but do)

Package: libstdc++6-4.7-dbg Version: 4.7.2-5 Severity: normal Dear Maintainer, With this package installed, running GDB on programs using libstdc++ is giving a confusing error message, which gives the impression that they haven't loaded, even though they actually do load: , | naesten@hydroge

Bug#692538: gcc-snapshot: FTBFS on hurd-i386: hurd-pthread.diff applied upstream

Package: gcc-snapshot Version: 20121106-1 Severity: important Tags: patch Hello, hurd-pthread.diff was applied upstream, so please remove it from gcc-snapshot, see attached change in rules.patch Samuel -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990

Bug#691476: gcc-doc: Another DMUA to zap?

Package: gcc-doc Version: 5:4 Severity: normal Dear Guo, It looks like you've got another DMUA flag to get rid of ... hopefully Steffen gets you into soon :-). Oh, and it looks like you've come up with a clever trick for determining the appropriate packages

Bug#691074: gcc-doc: Depends on docs for wrong gcc version

On Oct 21, 2012, at 12:34 AM, Guo Yixuan wrote: The packages in unstable are updated to 4.7 (or 4.6 on some archs)[1], I actually knew this; I can't think why I didn't say so in the report. and waiting for release team's unblock grant. This part I didn't know. Thanks! Thanks, also, for pic

Bug#691074: gcc-doc: Depends on docs for wrong gcc version

Package: gcc-doc Version: 5:3 Severity: serious Dear Maintainer, I've noticed that gcc-doc is still depending on the documentation for the aging GCC 4.4... -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimenta

Re: Everything's here.

Am, samuel bassey you can call me on, +2340865833902: -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/603367.76383...@smtp111-mob.biz.mail.ird.yahoo.com

Re: Everything's here.

Hi, pritty gudmorn hw are you doin, hope ur aright, hw ws ur nite. I reiceve ur mail, ur beautifull and am in love with you, can you pls sent me your contact adderss, your pix, and your number, i love to see you, also talk to you -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org w

Re: Bug#670422: libstarpu-dev: uninstallable in sid: too strict gcc dependency

sons (not only this), I'll actually probably drop the plugin support, because gcc 4.6 doesn't work with nvcc for part of our code, 4.7 neither for other reasons, and 4.6 is needed for plugins... Samuel -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of &qu

Bug#657962: gcc-defaults: Add gcc-plugin-dev?

Matthias Klose, le Mon 30 Apr 2012 12:41:49 +0200, a écrit : > On 30.01.2012 16:10, Samuel Thibault wrote: > > Samuel Thibault, le Mon 30 Jan 2012 11:17:42 +0100, a écrit : > >> I have a package which would like to build a gcc plugin. I should > >> however not make it b

Re: Bug#670422: libstarpu-dev: uninstallable in sid: too strict gcc dependency

ugin system enforces strict version dependency. Discussion happened to have a way to rebuild plugins automatically on gcc package upgrade etc. through a dpkg trigger, but nothing has actually happened yet. Samuel -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of &

Bug#668426: Add support Ada for GNU/Hurd

Svante Signell, le Thu 12 Apr 2012 14:46:22 +0200, a écrit : > On Thu, 2012-04-12 at 14:14 +0200, Samuel Thibault wrote: > > I will handle these, as well as commiting your latest working Ada patch, > > which thus does not need a bug report. > > Are you also submitting th

Bug#668425: Add support Ada for GNU/Hurd

I will handle these, as well as commiting your latest working Ada patch, which thus does not need a bug report. Samuel -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.

Re: gcc plugins and rebuilds

Samuel Thibault, le Wed 21 Mar 2012 23:50:41 +0100, a écrit : > Another way would be similar to dkms & co. That could also answer the question: how to make sure that the plugins are built for all installed versions of gcc. Samuel -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.deb

Re: gcc plugins and rebuilds

Another way would be similar to dkms & co. Samuel -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120321225041.gc10...@type.famille.thibault.fr

Re: gcc plugins and rebuilds

Ricardo Mones, le Wed 21 Mar 2012 18:16:04 +0100, a écrit : > On Wed, Mar 21, 2012 at 05:33:23PM +0100, Samuel Thibault wrote: > > Hello, > > > > One of my packages (starpu) will ship a gcc plugin (already in > > experimental). The problem is that the gcc plugin in

gcc plugins and rebuilds

mean that we have to rebuild the package on each gcc upload. Some other packages shipping plugins, such as dragonegg, bypass the test if some environment variable is set by the user, but that is really not safe. I'm afraid we will just have to rebuild each time? Samuel -- To UNSUBSCRIBE, ema

Bug#661859: gcc-snapshot: FTBFS on hurd-i386

Package: gcc-snapshot Version: 4.7-20120226-1 Severity: important Tags: patch User: debian-h...@lists.debian.org Usertags: hurd Hello, The src/libgcc/generic-morestack.c issue was fixed upstream, so please drop hurd-fixes.diff from gcc-snapshot as the attached patch does. Samuel -- System

Fwd: Bug#660955: RFS: gcc-4.6-doc-non-dfsg/4.6.2-1 -- documentation for GCC 4.6

I asked the BTS to CC debian-gcc on this, but the message seems to have gotten lost or something, so: -- Forwarded message -- From: Samuel Bronson Date: Thu, Feb 23, 2012 at 12:31 AM Subject: Bug#660955: RFS: gcc-4.6-doc-non-dfsg/4.6.2-1 -- documentation for GCC 4.6 To: Debian

Bug#661362: gcc-4.6: FTBFS on hurd-i386

Package: gcc-4.6 Version: 4.6.2-15 Severity: important Tags: patch Hello, The #652693 bug of gcc-4.7 was introduced in gcc-4.6 too, making it FTBFS on hurd-i386. Could you backport the hurd-fixes.diff patch to the 4.6 branch as the attached patch does? Thanks, Samuel -- System Information

Re: Fwd: RFS: gcc-4.5-doc-non-dfsg

On Tue, Feb 7, 2012 at 2:59 PM, Samuel Bronson wrote: > On Sun, Feb 5, 2012 at 7:17 AM, Nikita V. Youshchenko > wrote: >> In good old days when I had time and motivation to maintain gcc-doc, I've >> used git repos to managed entire thing. >> I've just creat

Re: Fwd: RFS: gcc-4.5-doc-non-dfsg

On Sun, Feb 5, 2012 at 7:17 AM, Nikita V. Youshchenko wrote: >> > I will try to look sometime soon, but can't promise when. > > Hello Samuel > > The gcc-doc thing you've done looks great, however it is incomplete. > > Complete solution consists of gcc-doc-defa

Re: Fwd: RFS: gcc-4.5-doc-non-dfsg

On Sun, Jan 29, 2012 at 1:49 PM, Nikita V. Youshchenko wrote: >> On Wed, Jan 25, 2012 at 3:17 PM, Samuel Bronson > wrote: >> > On Wed, Jan 25, 2012 at 2:10 PM, Matthias Klose > wrote: >> >> Samuel, thanks for doing this. However, I'm trying to get gcc-4.5 &

Bug#657962: gcc-defaults: Add gcc-plugin-dev?

Samuel Thibault, le Mon 30 Jan 2012 11:17:42 +0100, a écrit : > I have a package which would like to build a gcc plugin. I should > however not make it build-depend on a particular gcc-4.[567]-plugin-dev > package as the default version changes over time. Could gcc-defaults > also p

Bug#657962: gcc-defaults: Add gcc-plugin-dev?

package? Samuel -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.0.4 (SMP w/8 CPU cores) Locale

Re: Fwd: RFS: gcc-4.5-doc-non-dfsg

On Wed, Jan 25, 2012 at 3:17 PM, Samuel Bronson wrote: > On Wed, Jan 25, 2012 at 2:10 PM, Matthias Klose wrote: >> Samuel, thanks for doing this. However, I'm trying to get gcc-4.5 removed >> from unstable soonish, so I would like to see this for gcc-4.6 (and 4.7 as >

Re: Fwd: RFS: gcc-4.5-doc-non-dfsg

On Wed, Jan 25, 2012 at 2:10 PM, Matthias Klose wrote: > Samuel, thanks for doing this. However, I'm trying to get gcc-4.5 removed > from unstable soonish, so I would like to see this for gcc-4.6 (and 4.7 as > found in experimental). Could you do this?  Nikita, could you sponsor

Fwd: RFS: gcc-4.5-doc-non-dfsg

Dear GCC Maintainers, Perhaps I should have CC'd you in the first place, but here's a copy now: -- Forwarded message ------ From: Samuel Bronson Date: Sat, Jan 21, 2012 at 12:38 AM Subject: RFS: gcc-4.5-doc-non-dfsg To: debian-ment...@lists.debian.org Dear mentors, I

  1   2   >