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
> =
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
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
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 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
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
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
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 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
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
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
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
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
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
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.
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,
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
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:
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
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
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 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
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
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?
>
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
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
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: 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
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
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-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
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
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)(~(
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:
> > >
> >
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
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
Package: gcc-4.3
Version: 4.3.0-1
Severity: important
Hello,
gcc-4.3 currently FTBFS because of differing symbol lists:
dpkg-gensymbols: warning: debian/libstdc++6/DEBIAN/symbols doesn't match
completely debian/libstdc++6.symbols.hurd-i386
--- dpkg-gensymbols2oOICF 2008-03-23 13:51:10.77
Matthias Klose, le Sun 23 Mar 2008 17:35:40 +0100, a écrit :
> Samuel Thibault writes:
> > Package: gcc-4.3
> > Version: 4.3.0-1
> > Severity: important
> >
> > Hello,
> >
> > gcc-4.3 currently FTBFS because of differing symbol lists:
>
>
Package: gcc-4.1
Version: 4.1.2-19
Severity: important
Tags: patch
Hello,
When using -fstack-protector, gcc tries to link with libssp_nonshared,
which is not package, thus making a bunch of packages FTBFS. The
attached patch fixes that by making configure notice that (just like on
GNU/Linux and
Package: gcc-4.2
Version: 4.2.3-5
Severity: important
Tags: patch
Hello,
When using -fstack-protector, gcc tries to link with libssp_nonshared,
which is not package, thus making a bunch of packages FTBFS. The
attached patch fixes that by making configure notice that (just like on
GNU/Linux and G
Package: gcc-4.3
Version: 4.3.0-3
Severity: important
Tags: patch
Hello,
When using -fstack-protector, gcc tries to link with libssp_nonshared,
which is not package, thus making a bunch of packages FTBFS. The
attached patch fixes that by making configure notice that (just like on
GNU/Linux and G
fixed 483612 4.2.4-2
found 483613
thanks
Hello,
gcc-4.2=4.2.4-2 closed the bug which was intended for gcc-4.3, so
reopening that and closing the proper one.
Could you please fix the gcc-4.1 changelog into closing bug #483609?
Thanks,
Samuel
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with
Package: gcc-4.3
Version: 4.3.0-5
Severity: important
Tags: patch
Hello,
Depending on the build machine, gcc-4.3 currently FTBFS on hurd-i386
because of the symbol list and the usage of locales. See
http://buildd.debian-ports.org/fetch.php?&pkg=gcc-4.3&ver=4.3.1-1&arch=hurd-i386&stamp=1212944993
found 483613 4.3.1-1
found 483612 4.2.4-2
thanks
Eerf, the libssp_gnu.dpatch isn't getting applied because hurd-i386 is
in ssp_no_archs, please apply attached patch to gcc-[1-3].
Samuel
Index: debian/rules.defs
===
--- debian/rules.d
Package: gdc-4.2
Version: 4.2.3-1
Severity: wishlist
Hello,
gcc-4.2 upgraded to 4.2.4-1, could you do the same for gdc? That
would actually fix bug 482519. It would also permit to install gdc on
hurd-i386: for now gcc-defaults' gdc depends on gdc-4.2 (>= 4.2.4-1)
there.
Samuel
-- System Infor
Hello,
I'm starting thinking about _software_ speech synthesis in d-i. A
simple solution would be to use espeakup, which connects the espeak
software speech synthesis to speakup. That would however depend on:
- sound kernel modules
- a libespeak udeb
and the latter depends on
- a libstdc++ ude
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
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: 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'), (
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: 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
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
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
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
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
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
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
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
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
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/
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
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
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).
> Otherwise this will prevent gcc-4.6 from migrating to testing.
For various reasons (not
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, '
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
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
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
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
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
: Development Librari
pn libmudflap0-4.2-dev(no description available)
-- no debconf information
--
Samuel Thibault <[EMAIL PROTECTED]>
ya(ka|ma|to)* ca existe une fois sur 2 au japon, c'est facile ;-)
-+- #ens-mim au japon -+-
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
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
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
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
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
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
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
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
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
: 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.
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
.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
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
ment Librari
pn libmudflap0-dev (no description available)
-- no debconf information
--
Samuel Thibault <[EMAIL PROTECTED]>
>Ever heard of .cshrc?
That's a city in Bosnia. Right?
(Discussion in comp.os.linux.misc on the intuitiveness of commands.)
packages gcj-4.1 recommends:
ii fastjar 1:4.1.1-21 Jar creation utility
-- no debconf information
#! /bin/sh -e
# Description: java support for GNU/Hurd
# Author: Robert Millan, Petr Salinger, Samuel Thibault
dir=
if [ $# -eq 3 -a "$2" = '-d' ]; then
pdi
libmudflap0-dev(no description available)
-- no debconf information
--
Samuel Thibault <[EMAIL PROTECTED]>
J'ai un gros problème: j'ai cet exercice à rendre demain lundi, mais ma
TI 89 ne sait pas le faire...
Est-ce que quelqu'un pourrait m
Hi,
Matthias Klose, le Fri 09 Mar 2007 09:44:55 +0100, a écrit :
> thanks for the patch. Please could you update it for gcj-4.1 from
> experimental?
Mmm, there's something odd with gcj-4.1 from experimental: it
build-depends on ecj, which itself depends on gij-4.1 (>= 4.1.2-1). How
can I break th
Samuel Thibault, le Sat 10 Mar 2007 00:48:31 +0100, a écrit :
> Matthias Klose, le Fri 09 Mar 2007 09:44:55 +0100, a écrit :
> > thanks for the patch. Please could you update it for gcj-4.1 from
> > experimental?
>
> Mmm, there's something odd with gcj-4.1 from experimen
Mmm, gcj-4.1 build-depends on itself, gcj-4.1. Is that on purpose? (the
compilation seems to need it indeed).
Samuel
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
-gcc netbsd-archs-gcc
endif
+ifeq ($(DEB_TARGET_ARCH_OS),hurd)
+ debian_patches += libjava-hurdfix
+endif
ifdef DEB_CROSS
debian_patches += cross-include cross-fixes
#! /bin/sh -e
# Description: java support for GNU/Hurd
# Author: Robert Millan, Petr Salinger, Samuel Thibault
dir=
if [ $# -eq
Hi,
Thomas Schwinge, le Sun 29 Jul 2007 17:24:34 +0200, a écrit :
> > *startfile: %{!shared: %{!static: %{pg:gcrt0.o%s} %{!pg:%{p:gcrt0.o%s}
> > %{!p:crt1.o%s}}} %{static: %{pg:gcrt0.o%s} %{!pg:{%p:gcrt0}}
>
> Here is a typo, I suppose: ^
Yes. Here is an fixed pat
Samuel Thibault, le Sat 21 Jul 2007 20:57:22 +0200, a écrit :
> Here are updated patches.
Btw, they are needed in gcj-4.2 too of course (and they already do apply
fine).
Samuel
Here is for gcj-4.2 a patch to be appended to the previously posted
libjava-hurdfix.dpatch for gcj-4.1.
Samuel
Index: libjava/java/lang/natPosixProcess.cc
===
--- libjava/java/lang/natPosixProcess.cc(révision 127274)
+++ libja
Hi,
Matthias Klose, le Sun 12 Aug 2007 20:34:26 +0200, a écrit :
> Please send patches against the current debian svn, and actively
> forward tested patches to upstream.
What is "the current debian svn"?
I have already forwarded those patches upstream, but they seem to take a
lot of time just to
Samuel Thibault, le Sun 12 Aug 2007 20:42:50 +0200, a écrit :
> Matthias Klose, le Sun 12 Aug 2007 20:34:26 +0200, a écrit :
> > Please send patches against the current debian svn, and actively
> > forward tested patches to upstream.
>
> What is "the current debi
Matthias Klose, le Sun 12 Aug 2007 20:55:48 +0200, a écrit :
> all patches which were approved, are comitted to the trunk.
Oh, indeed, I must have missed the update, sorry.
> sorry, but please submit patches for 4.1 and 4.2 as debian patches to
> the debian bts.
That's OK. These svn urls should
Hi,
Here is an update of the libjava-hurdfix patch: part of it is already in
libjava-maxhostnamelen.dpatch now.
I'm working on the port to 4.2.
Samuel
Index: debian/patches/libjava-hurdfix.dpatch
===
--- debian/patches/libjava-hurdf
reopen 40
thanks
Unfortunately no, as I said in my latest mail (and provided a patch),
libjava.maxhostnamelen.dpatch does part of what libjava-hurdfix.dpatch
already does, so that they conflict when building on hurd-i386
(libjava-hurdfix is only enabled on hurd-i386).
Samuel
--
To UNSUBSCR
Samuel Thibault, le Mon 13 Aug 2007 10:51:30 +0200, a écrit :
> Here is the patch to apply to the gcc-4.2 svn repository for fixing
> the build on GNU/Hurd.
Oops, I hadn't noticed that you had dropped libjava-maxhostnamelen. Here
is a patch against revision 2343.
Samuel
Index: debian/
urd
+# Author: Robert Millan, Petr Salinger, Samuel Thibault
+
+dir=
+if [ $# -eq 3 -a "$2" = '-d' ]; then
+pdir="-d $3"
+dir="$3/"
+elif [ $# -ne 1 ]; then
+echo >&2 "`basename $0`: script expects -patch|-unpatch as argument"
+
1 - 100 of 133 matches
Mail list logo
