Hello,
John Paul Adrian Glaubitz, le mer. 19 juin 2024 13:22:52 +0200, a ecrit:
> gcc-14 needs to build-depend on cargo on hurd-i386 to be able to build gccrs
> [1]:
>
>configure: error: cargo is required to build rust
More precisely, rs_no_systems was not actually working. And converse
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
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
Source: gcc-14
Version: 14-20240201-3
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
Hello,
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 (kfr
Package: gcc-13
Version: 13.2.0-13
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
Hello,
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 (kfreeb
diff --git a/debian/patches/hurd-amd64.diff b/debian/patches/hurd-amd64.diff
new file mode 100644
index 000..e7288ea
--- /dev/null
+++ b/debian/patches/hurd-amd64.diff
@@ -0,0 +1,127 @@
+commit 5707e9db9c398d311defc80c5b7822c9a07ead60
+Author: Samuel Thibault
+Date: Sat May 6 13:50:36
Package: libelf-dev
Version: 0.189-2
Severity: serious
Tags: patch
Justification: Makes glib2.0 FTBFS
Hello,
Since version 0.189, libelf.pc has libzstd in its Requires.private.
The libelf-dev package should thus depend on the libzstd-dev package,
otherwise we get:
$ pkg-config --cflags libelf
P
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: (990, 'testi
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?
>
on
--
Samuel
Moralité : le modem et le cablerouteur font comme les filles, ils
papotent toute la journée.
-+- RB in NPC : Et en plus, ils ne parlent que de bits -+-
commit 266bfee4ef2609ef3fb7e511748c37783271df50
Author: Samuel Thibault
Date: Sat Sep 19 13:24:54 2020 +0200
Limit syste
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
I see that you have added --with-arch=i686 explicitly in rules2,
but the thing is: it is *already* what gets enabled by default
without specifying anything, just like it happens on linux-i386 and
kfreebsd-i386.
Keeping that special case will yet once more leave a corner case that'll
bite us sooner
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
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
dfsg-2
Versions of packages gcc-9 recommends:
ii libc6-dev 2.30-8
Versions of packages gcc-9 suggests:
ii gcc-9-doc 9.3.0-1
pn gcc-9-locales
ii gcc-9-multilib 9.3.0-12
-- no debconf information
commit 2206ac18f2c0bc3515009f56d0a7cdc01b644a15
Author: Samuel Thibault
Date: Mon May 18 14:
Hello,
On 20.11.19 11:43, Fabian Kloetzl wrote:
> 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_attribute(ifunc) which, unfortunately, evaluates to 1 on said
> platforms. A minimal testcase
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
Matthias Klose, le mar. 17 sept. 2019 18:40:04 +0200, a ecrit:
> use the bug tracker to submit debian related patches. I'm not going to
> review merge requests, but unfortunately I can't disable them.
In "Settings" -> "General" -> "Visibility, project features,
permission", there is a "Merge reque
libgomp1-dbg
pn libitm1-dbg
pn liblsan0-dbg
pn libquadmath0-dbg
pn libtsan0-dbg
pn libubsan1-dbg
-- no debconf information
--
Samuel
ça gaze ?
prout
-+- #ens-mim - ouvrez les fenêtres ! -+-
commit 5aabd4e720ac112f080aaca1e22e7de7887894d8
Author: Samue
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
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:
> > >
> >
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:
>
> CC i386-gnu-complex/obj/src/vec/vec/interface/vector.o
> ../../src/init2.c:52: MPFR assertion failed: p >= 2 && p <=
> ((mpfr_prec_t)((mpfr_uprec_t)(~(
Hello,
Svante Signell, on sam. 10 mars 2018 19:33:35 +0100, wrote:
> Attached is the updated patch, src_libgo_build.diff, to build gccgo properly
> on
> Debian GNU/Hurd on gcc-7 (7-7.3.0-{8,9,10}) again after the update of glibc to
> 2.26+
I have updated the gcc-7 package in Debian, thanks!
Sam
Package: gcc-7
Version: 7.2.0-18
Severity: important
User: debian-h...@lists.debian.org
Usertag: hurd
Hello,
We have eventually fixed the issue we had with PIE: gdb support.
So could you please enable PIE by default? That should fix the build of
gpgme1.0, thus unlocking a lot of packages.
Samue
Hello,
Svante Signell, on lun. 06 nov. 2017 16:36:39 +0100, wrote:
> Another issue is that /proc/self/exe has to return an absolute path for the
> built program go-7 to execute properly. This is solved by a pending patch for
> glibc in Debian and will be available in the next upload of glibc-2.24.
Lumin, on sam. 13 mai 2017 05:59:24 +, wrote:
> > This was documented in NEWS.Debian.gz. Having to use "--compiler-options
> > -fPIC" was however not documented in NEW.Debian.gz, at least that should
> > be done.
>
> Well, what do you think we can to to deal with this bug?
I Cc-ed gcc, llvm a
Hello,
Lumin, on dim. 07 mai 2017 02:29:46 +, wrote:
> I'm not sure whether this bug should be marked as serious. Since your test
> cases are mixing the default cc (GCC-6) and clang-3.8 together.
Well, there is no choice about this: not doing so leads to:
cc-c -o test.o test.c
nvcc -c t
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
Package: nvidia-cuda-toolkit
Version: 8.0.44-3
Severity: serious
Justification: breaks basic use of nvcc
Hello,
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
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
Hello,
Svante Signell, on Fri 25 Nov 2016 20:57:26 +0100, wrote:
> Another more annoying gnumch/hurd/glibc bug is that the
> built program go (go-6 in Debian) gets killed when executed from the
> shell vi path, but not when issued directly: /usr/bin/go-6 works fine.
> go-6
> Segmentation fault (c
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
Svante Signell, on Wed 07 Dec 2016 14:52:35 +0100, wrote:
> Since go does not have a preprocessor allowing conditional code paths this is
> how it should be done (and as I did):
> http://blog.ralch.com/tutorial/golang-conditional-compilation/
Ok, but then I'd say move the function which change to
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
Hello,
Svante Signell, on Sun 27 Nov 2016 17:33:52 +0100, wrote:
> > > Index: gcc-6-6.2.1-4.1/src/libgo/go/syscall/wait.c
> > > ===
> > > --- gcc-6-6.2.1-4.1.orig/src/libgo/go/syscall/wait.c
> > > +++ gcc-6-6.2.1-4.1/src/libgo/go/sysc
Hello,
Nice work!
Mmm, why making changes in each file in a separate patch? I don't think
it makes things easier to review, I'd say rather send a big patch, it's
altogether that it makes sense anyway.
> Index: gcc-6-6.2.1-4.1/src/libgo/Makefile.in
> =
Matthias Klose, on Fri 22 Apr 2016 00:47:09 +0200, wrote:
> >With separate -unstripped (or whatever) packages, they could be
> >installed by admin choice in those situations.
>
> well, admin choice is usually not the default. So this would miss the buildds.
Making the buildds install extra packag
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
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-
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-bin/bugreport.cgi?bug=781424
I'm currently trying to build a simple fix: copy/paste the clock_getres
C interface from Linux, as
Matthias Klose, le Tue 24 Mar 2015 16:09:27 +0100, a écrit :
> > I guess this
> > was done in order to be able to use the same omp.h on both i386 and
> > amd64, but I don't think this is still needed now that omp.h is in
> > arch-specific
> >
> > /usr/lib/gcc/x86_64-linux-gnu/5/include/omp.h
> >
>
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
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
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,
The latest Debian hurd package has a workaround to mimic Linux' behavior
of never returning more than 4095 bytes for non-blocking pipe reads,
which fixes the 'expect' behavior.
gcc-5 is currently building on the mahler buildd with it, it'll take a
few hours to complete, but by comparing the first
Hello,
Trying a bit on Linux with buffer sizes, this really is an issue between
tcl and expect. It happens to work on Linux only by luck because Linux
never returns more than 4095 bytes on ptys. As you described earlier,
what happens is:
- expect has a 6001 bytes buffer
- tcl will read() by 4096
Thomas Schwinge, le Sun 18 Jan 2015 17:34:00 +0100, a écrit :
> (Can you now reproduce the issue?)
Yes.
> Any comments on that already? (I don't feel like
> committing such a change without understanding it.)
>
> --- term/ptyio.c
> +++ term/ptyio.c
> @@ -331,7 +331,7 @@ pty_io_read (struct triv
Thomas Schwinge, le Thu 09 Oct 2014 14:02:39 +0200, a écrit :
> #!/usr/bin/expect -f
>
> # Doesn't seem to matter.
> #stty -cooked
> stty cooked
>
> #spawn sh -c "/media/erich/home/thomas/tmp/gcc/755295.build/gcc/xgcc.real
> -B/media/erich/home/thomas/tmp/gcc/755295.b
Hello,
Thomas Schwinge, le Thu 09 Oct 2014 16:50:12 +0200, a écrit :
> It is, after all, a regression, due to a fix "recently" applied by
> Richard:
>
> commit 1cfdceba98c380ad1cebb3a6b3d1f141d852c691
> Author: Richard Braun
> Date: Mon Oct 14 20:48:25 2013 +0200
>
> t
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
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
with a subje
Hello,
I've dug a bit more the java failures we've been encountering for some
time. The particular case of simply running gjdoc was helpful: an
object gets allocated, then other happens, then the object gets used,
but its method table is completely nuts. It happens that the class
field of the ob
Hello,
Matthias Klose, le Wed 20 Aug 2014 23:39:40 +0200, a écrit :
> I backported the proposed fix for PR61841 in 4.9.1-6, however this doesn't
> seem
> to fix things.
I don't see how their proposed fix could fix the issue we are having on
GNU/Hurd.
The issue mentioned on https://gcc.gnu.org/m
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
>libpthread)
>
> b) fix pthread_key_create in Hurd's libpthr
tony mancill, le Wed 09 Jul 2014 22:26:19 -0700, a écrit :
> (gdb) bt
> #0 0x012ab278 in gnu.classpath.tools.gjdoc.Main.start(java.lang.String[])int
> (
> this=@80c8eb0, args=@8099f98)
> at
> ../../../../../src/libjava/classpath/tools/gnu/classpath/tools/gjdoc/Main.java:1050
This is:
Control: severity -1 important
Hello,
Matthias Klose, le Fri 11 Jul 2014 15:48:56 +0200, a écrit :
> > Shouldn't the package for kfreebsd* have the files in a different
> > sub-directory? linux just feels wrong on kfreebsd. I expect (but don't
> > know for sure) that the resolver is smart enough
Matthias Klose, le Wed 16 Jul 2014 03:55:30 +0200, a écrit :
> 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]
>
>
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 UNSUBSCRIBE,
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/port/simgrid/simgrid-3.11.1/src/bindings/java/org/simg
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
Matthias Klose, le Mon 23 Jun 2014 15:50:49 +0200, a écrit :
> so for now packages building jni bindings should have both /include
> and /include/linux on the include path.
Well, this looks a bit odd. Upstream is used to just
-I${JAVA_HOME}/include, and it works fine with other JDKs, should it
re
Matthias Klose, le Thu 05 Jun 2014 11:49:31 +0200, a écrit :
> Am 04.06.2014 18:44, schrieb Ludovic Brenta:
> > 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-depende
Package: gcc-4.9-plugin-dev
Version: 4.9.0-2
Severity: serious
Justification: Renders package unusable
Hello,
Some headers seem to be missing to make using plugins workable at all
with gcc-4.9:
$ cat test.cpp
#include
#include
#include
int main(void) {
return 0;
}
$ g++-4.9 test.cpp
Package: gcj-4.8-jdk
Version: 4.8.1-5
Severity: important
Hello,
See this build log for the details:
https://buildd.debian.org/status/fetch.php?pkg=liblouisutdml&arch=kfreebsd-amd64&ver=2.4.0-1&stamp=1371429318
But basically the interesting part is:
/bin/bash ../libtool --tag=CC --mode=comp
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, '
Andreas Beckmann, le Wed 25 Apr 2012 15:00:20 +0200, a écrit :
> Having the dependency on gcc-4.6 that strict implies rebuilding starpu
> for each gcc upload (a binNMU with appropriate dep-wait should work).
> Otherwise this will prevent gcc-4.6 from migrating to testing.
For various reasons (not
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
Andreas Beckmann, le Wed 25 Apr 2012 15:00:20 +0200, a écrit :
> Having the dependency on gcc-4.6 that strict implies rebuilding starpu
> for each gcc upload (a binNMU with appropriate dep-wait should work).
Yes, that's actually the intent of the debian dependency, because the
gcc plugin system en
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
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.debian.org/
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
Yves-Alexis Perez, le Wed 21 Mar 2012 22:47:11 +0100, a écrit :
> Can't the plugin be rebuilt when needed (meaning, when it's used to
> actually build something)?
That'd make it quite more involved to use. ATM you just need to pass
-fplugin=/usr/lib/.../libfoo.so to gcc.
Another way would be simi
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
Hello,
One of my packages (starpu) will ship a gcc plugin (already in
experimental). The problem is that the gcc plugin infrastructure checks
for exact version matching (in plugin_default_version_check()), i.e.
plugins are supposed to be loaded only by the exact gcc that built it.
That would mean
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 Infor
.6-multilib 4.6.2-12
pn libgcc1-dbg 1:4.7-20120129-1
pn libgomp1-dbg
pn libmudflap0-4.6-dev
pn libmudflap0-dbg
pn libquadmath0-dbg
-- no debconf information
--
Samuel Thibault
RR> Ce que je cherche à démontrer, c'est qu'il est injuste de fa
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
: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
--
Samuel Thibault
"I once witnessed a long-winded, month-long flamewar over the use of
mice vs. trackballs...It was very silly."
(By Matt Welsh)
--
To UNSUBSCRIBE, email to debian-gcc-requ.
Package: gcc-4.7
Version: 4.7-20111217-1
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
Hello,
gcc-4.7 currently FTBFS on hurd-i386 due to two things:
- hurd-changes.diff doesn't apply any more due to configuration
revamping, attached is an updated version.
- g
Matthias Klose, le Mon 19 Dec 2011 00:55:12 +0100, a écrit :
> 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).
I am doing it for hurd already, patch pe
Hello,
Matthias Klose, le Thu 18 Aug 2011 23:07:15 +0200, a écrit :
> 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*.
>
> Bas
Hello,
Ondřej Surý, le Wed 08 Dec 2010 10:30:46 +0100, a écrit :
> Trang fails with Bus error when rebuilding rng files for opendnssec on
> kfreebsd-amd64:
and it doesn't happen on kfreebsd-i386.
I'm getting the following backtrace on asdfasdf.debian.net:
0x000803cfa2c7 in __pthread_sigsus
Package: gcc-4.6
Version: 4.6.0-10
Severity: normal
Hello,
Since gcc started using --no-add-needed by default, there are issues
with weak references, see attached testcase:
- libthread represents a thread library, which here only provide the
"cancel" symbol.
- libA is a library which uses the
found 624743 4.6.0-8
thanks
Hello,
hurd-i386 is also hit by the bug.
Andreas Metzler, le Fri 06 May 2011 20:16:49 +0200, a écrit :
> On 2011-05-05 Kees Cook wrote:
> > Hi! Thanks for this report. I can't reproduce this segfault. I tried the
> > builds both amd64 and i386, and both build fine wi
suggests no packages.
-- no debconf information
--
Samuel Thibault
update-menus: relocation error: update-menus: symbol
_ZNSt9basic_iosIcSt11char_traitsIcEE4initEPSt15basic_streambufIcS1_E, version
GLIBCPP_3.2 not defined in file libstdc++.so.5 with link time reference
quoi que ça peut bien vouloi
Kurt Roeckx, le Tue 26 Apr 2011 21:28:57 +0200, a écrit :
> Is there a reason not to switch the remaining (release) arches
> (ia64, kfreebsd-*, sparc, s390)? Maybe hurd-i386 too?
There's no real reason to defer hurd-i386, as it's basically like i386,
and the key packages (glibc/hurd/gnumach) alre
Florian Weimer, le Tue 16 Nov 2010 19:49:57 +0100, a écrit :
> * Roland McGrath:
>
> >> I can't see why you think --as-needed is fundamentally wrong or
> >> unnecessary.
> >
> > It is fundamentally wrong because -lfoo means I demand that the
> > initializers of libfoo.so run, whether or not I cal
Steve Langasek, le Tue 16 Nov 2010 09:14:40 -0800, a écrit :
> I don't argue that this makes --as-needed *correct* as a default, but I
> think it's clear how using --as-needed may benefit a distribution in terms
> of reducing churn when library dependencies change.
We agree on the second part, but
Bernhard R. Link, le Tue 16 Nov 2010 11:01:20 +0100, a écrit :
> * Kurt Roeckx [101114 14:08]:
> > People have been claiming that constructors or init section are a
> > possible problem. I have yet to see an example where it breaks.
>
> The following example is a bit constructed, but shows a sil
Matt Turner, le Mon 15 Nov 2010 19:51:10 -0500, a écrit :
> On Mon, Nov 15, 2010 at 7:24 PM, Roger Leigh wrote:
> > What's the actual problem --as-needed is trying to solve?
> >
> > The answer is mainly unwanted libraries being linked in as a result
> > of using pkg-config (and various other -conf
reopen 584819
thanks
Oops, sorry, it looks like my patch toold is quite laxist and accepted a
not so exact patch, but buildds & such don't accept that. The attached
patch should fix the hooks content.
It also moves hurd-changes to after the snapshot barrier, now that it
only contains long-term c
pn libgcc1-dbg(no description available)
pn libgomp1-dbg (no description available)
pn libmudflap0-4.5-dev(no description available)
pn libmudflap0-dbg(no description available)
-- no debconf information
--
Samuel Thiba
Package: gcc-snapshot
Version: 20100530-1
Severity: normal
Tags: patch
Hello,
gcc-snapshot currently FTBFS on hurd-i386 because Debian GNU/Hurd
doesn't strictly follow the same rules as the main GNU/Hurd: /include
does not exist on Debian GNU/Hurd. The attached patch fixes this by
dropping almost
nstable'), (500, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
--
Samuel Thibault
I am the "ILOVEGNU" signature vir
Kees Cook, le Tue 27 Oct 2009 14:11:43 -0700, a écrit :
> On Mon, Oct 26, 2009 at 11:14:25AM +0100, Bastian Blank wrote:
> > On Sun, Oct 25, 2009 at 11:55:25AM -0700, Kees Cook wrote:
> > > I would like to propose enabling[1] the GCC hardening patches that Ubuntu
> > > uses[2].
> >
> > How do they
Package: libffi
Version: 3.0.7-1
Severity: important
Hello,
On hurd-i386, applications can't find ffi.h because it is put in
/usr/include/i486-gnu, but on hurd-i386 is not compiled with multiarch
support. I guess what happens is that the filter in debian/rules
catches hurd-i386, but it shouldn't
Oops, I overwrote the patch with something else in between, here is the
proper patch.
Samuel
Index: debian/control
===
--- debian/control (révision 3602)
+++ debian/control (copie de travail)
@@ -4,7 +4,7 @@
Maintainer: Deb
Package: gcc-defaults
Version: 1.80
Severity: normal
Tags: patch
Hello,
Now that hurd-i386 has gcj-4.3, could you enable java for it as per
attached patch?
Thanks
Samuel
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (
Hello,
Debian Bug Tracking System, le Sun 19 Apr 2009 16:06:12 +, a écrit :
> #524671: gcj-4.3: Fix gcj build on hurd-i386
> It has been closed by Matthias Klose .
Cool!
>[Samuel Tardieu]
>* Fix gcj build on hurd-i386. Closes: #524671.
Errr, no, Samuel Tardieu is somebody else :)
S
Package: gcj-4.3
Version: 4.3.3-3
Severity: important
Tags: patch
Hello,
The attached patch applies upstream fixes that make gcj buildable on
hurd-i386:
- set thread_file to posix in config.gcc (as in gcc upstream)
- fix GNU/Hurd thread bits in boehm-gc (as in boehm-gc upstream)
The same patch
1 - 100 of 133 matches
Mail list logo
