Re: Everything's here.

[Samuel]

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
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/613993.89715...@smtp106-mob.biz.mail.ird.yahoo.com

Re: Everything's here.

[Samuel]

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: Hurd port for gcc go PATCH 1-4(23)

[Samuel Thibault]

x27; | ${CC} -x c -
>egrep '#define E[A-Z0-9_]+ ' | \
>sed -e 's/^#define \(E[A-Z0-9_]*\) .*$/const \1 = Errno(_\1)/' >> ${OUT}
>  
> +# Special treatment of EWOULDBLOCK for GNU/Hurd
> +# /usr/include/bits/errno.h: #define EWOULDBLOCK EAGAIN
> +if egrep 'define EWOULDBLOCK EAGAIN' gen-sysinfo.go > /dev/null 2>&1; then
> +  egrep '^const EWOULDBLOCK = Errno(_EWOULDBLOCK)' ${OUT} | \
> +sed -i -e 's/_EWOULDBLOCK/_EAGAIN/' ${OUT}
> +fi
> +

Err, why using the second egrep at all? sed -i will work directly on the
file, it won't care about its input. Doesn't this just work already?

# Special treatment of EWOULDBLOCK for GNU/Hurd
# /usr/include/bits/errno.h: #define EWOULDBLOCK EAGAIN
if egrep 'define EWOULDBLOCK EAGAIN' gen-sysinfo.go > /dev/null 2>&1; then
sed -i -e 's/_EWOULDBLOCK/_EAGAIN/' ${OUT}
fi


Svante Signell, on Fri 25 Nov 2016 21:04:58 +0100, wrote:
> * src_libgo_runtime_netpoll.goc.diff: Fix restricted word bug.
>   Rename variable errno to errno1.
> * src_libgo_go_os_os_test.go.diff: Allow EFBIG return code to big
> seeks.
> * src_libgo_go_syscall_syscall_gnu_test.go: New file:
>   Define Type and Whence as 32bit in syscall.Flock_t
> * src_libgo_testsuite_gotest.diff: Remove comm option for ps -o.
> * add-gnu-to-libgo-headers.diff:
>   Add gnu to +build entry in file headers included in the build.
>   FIXME:  

I can't find these in the patches you sent.



> Index: gcc-6-6.2.1-4.1/src/libgo/testsuite/gotest
> ===
> --- gcc-6-6.2.1-4.1.orig/src/libgo/testsuite/gotest
> +++ gcc-6-6.2.1-4.1/src/libgo/testsuite/gotest
> @@ -618,7 +618,11 @@ xno)
>   wait $pid
>   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

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

[Samuel Thibault]

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/syscall/wait.c
> > > @@ -8,6 +8,9 @@
> > > OS-independent.  */
> > >  
> > >  #include 
> > > +#ifndef WCONTINUED
> > > +#define WCONTINUED 0
> > > +#endif
> > >  #include 
> > >  
> > >  #include "runtime.h"
> > 
> > That looks odd at best: WCONTINUED can't be defined at this place
> > anyway, so it'll get defined to 0. Fortunately the sys/wait.h
> > definition
> > would override this. But then wait.c will define something which does
> > not make sense since WCONTINUED is not implemented. Better use #ifdef
> > WCONTINUED inside the Continued function, to always return 0 when
> > it's
> > not defined.
> > 
> 
> I've been implementing that version too, with no visible differences.

"no visible differences" doesn't mean there is none :)

> But as you wish, an updated patch is attached.

 _Bool
 Continued (uint32_t *w)
 {
+#ifndef WCONTINUED
+  *w = 0;
+  return 0;
+#else
   return WIFCONTINUED (*w) != 0;
+#endif
 }

Err, recheck the semantic of WCONTINUED again, it doesn't modify its
parameter, it just tests its value.

Do as I said, just return 0.



> This is for upstream to decide.

I'm just afraid they'd just frown on the code submission and not take
the time to explain how they want it to look like if we don't raise the
discussion ourselves.



> > And
> > src_libgo_go_syscall_syscall_gnu_test.go: New file:
> >   Define Type and Whence as 32bit in syscall.Flock_t
> > 
> > Again, you'll probably have to discuss with upstream to see how they
> > prefer to make it configurable rather than forking the whole file.
> >
> 
> I tried to patch the syscall_unix_test.go file, but did not succeed. 
> Definitely if runtime.GOOS == "GNU" ... else ... or switch runtime.GOOS
> ... does not work. The compiler sees all code and complains, also the
> else part of the code :( Therefore I created a new file.

Then ask upstream how they think it can and should be done.



> > > @@ -4431,7 +4505,7 @@ mostlyclean-local:
> > >   find . -name '*-testsum' -print | xargs rm -f
> > >   find . -name '*-testlog' -print | xargs rm -f
> > >  
> > > -CLEANFILES = *.go *.gox goc2c *.c s-version libgo.sum libgo.log
> > > +CLEANFILES = *.go *.gox goc2c *.c s-* libgo.sum libgo.log
> > 
> > This seems unrelated?
> > 
> No, this is not unrelated: With this patch you can
> make -C build/i686-gnu/libgo clean
> make -C build/i686-gnu/libgo
> to rebuild libgo. Otherwise libcalls.go is not regenerated,
> mksysinfo.sh is not run etc. 

That's still unrelated to the matter here: porting go to GNU/Hurd.  It
looks like a bug fix which is completely independant from GNU/Hurd.

> > Svante Signell, on Fri 25 Nov 2016 21:04:58 +0100, wrote:
> > > * src_libgo_runtime_netpoll.goc.diff: Fix restricted word bug.
> > >   Rename variable errno to errno1.
> > > * src_libgo_go_os_os_test.go.diff: Allow EFBIG return code to big
> > > seeks.
> > > * src_libgo_go_syscall_syscall_gnu_test.go: New file:
> > >   Define Type and Whence as 32bit in syscall.Flock_t
> > > * src_libgo_testsuite_gotest.diff: Remove comm option for ps -o.
> > > * add-gnu-to-libgo-headers.diff:
> > >   Add gnu to +build entry in file headers included in the build.
> > >   FIXME:  
> > 
> > I can't find these in the patches you sent.
> 
> It is in the last mail: patch 19-23(23)

Ah, sorry, mutt had pasted the content of the attached files without
putting the file names.

> > > Index: gcc-6-6.2.1-4.1/src/libgo/testsuite/gotest
> > > ===
> > > --- gcc-6-6.2.1-4.1.orig/src/libgo/testsuite/gotest
> > > +++ gcc-6-6.2.1-4.1/src/libgo/testsuite/gotest
> > > @@ -618,7 +618,11 @@ xno)
> > >   wait $pid
> > >   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.
> 
> 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)

[Samuel Thibault]

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
> > +  *w = 0;
> > +  return 0;
> > +#else
> >    return WIFCONTINUED (*w) != 0;
> > +#endif
> >  }
> > 
> > Err, recheck the semantic of WCONTINUED again, it doesn't modify its
> > parameter, it just tests its value.
> > 
> > Do as I said, just return 0.
> 
> No I can't the compiler complains about an unused variable. Maybe
> adding an __attribute__((unused)) to the function header?

For instance.  See how it is done in the rest of the code.

> > > This is for upstream to decide.
> > 
> > I'm just afraid they'd just frown on the code submission and not take
> > the time to explain how they want it to look like if we don't raise
> > the
> > discussion ourselves.
> > 
> 
> Should we propose these changes upstream? Or do you mean something
> else? 

I mean proposing explicitly to upstream, yes, so they don't have to
take the time to explain.

> > Then ask upstream how they think it can and should be done.
> 
> Upstream would be Ian Lance Taylor, right?

I don't know.

> > > > > -CLEANFILES = *.go *.gox goc2c *.c s-version libgo.sum
> > > > > libgo.log
> > > > > +CLEANFILES = *.go *.gox goc2c *.c s-* libgo.sum libgo.log
> > > > 
> > > > This seems unrelated?
> > > > 
> > > No, this is not unrelated: With this patch you can
> > > make -C build/i686-gnu/libgo clean
> > > make -C build/i686-gnu/libgo
> > > to rebuild libgo. Otherwise libcalls.go is not regenerated,
> > > mksysinfo.sh is not run etc. 
> > 
> > That's still unrelated to the matter here: porting go to
> > GNU/Hurd.  It
> > looks like a bug fix which is completely independant from GNU/Hurd.
> 
> Yes it is not Hurd-related. Maybe this should be filed as a separate
> bug. To gcc upstream directly?

Yes.

> > > > 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 :)
> 
> Sorry, I need help for doing this. Any other Hurd developer listening?

See spec_abbrevs in utils/ps.c, I guess it's a matter of adding
{"Comm=args"} in the list.

Samuel

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

[Samuel Thibault]

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 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)

[Samuel Thibault]

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 be tedious to maintain.
> 
> One problem is the file go/syscall/libcall_posix-1.go, derived
> from go/syscall/libcall_posix.go but _removing_ four function definitions:
> mount, madvise, mlockall and munlockall.

That's not a problem: move them out to another file, and include that
file in the non-gnu case, but do not include that file in the gnu case.

Actually it's even odd to see mount among them, it's not a standard
posix interface.

Samuel

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

[Samuel Thibault]

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 (core dumped)

I've had a quick look by adding printfs in go-main.c and further to see
up to where it goes before crashing.  It crashes in

src/libgo/runtime/go-caller.c

in function __go_get_backtrace_state, inside the stat() call in:

if (__builtin_strchr (filename, '/') == NULL)
  filename = NULL;

if (stat (filename, &s) < 0 || s.st_size < 1024)
  filename = NULL;

filename of course doesn't start with '/' (it's argv[0]), and thus NULL
is passed to stat(). It happens that by luck on Linux this just returns
an EFAULT error, but that's sheer luck :) This should probably be turned
into e.g.:

if (!filename || stat (filename, &s) < 0 || s.st_size < 1024)
  filename = NULL;

as the attached patch does, which should really be applied or done
any other way.



Then calling go-6 brings this:

  fatal error: libbacktrace could not find executable to open

That's inside src/libbacktrace/fileline.c, the fileline_initialize
function, which tries the above filename (and thus fails), then
getexecname() (which is not implemented), then /proc/self/exe, which is
not implemented, then /proc/curproc/file which is even 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,7 @@
 argv[0] (http://gcc.gnu.org/PR61895).  It would be nice to
 have a better check for whether this file is the real
 executable.  */
-  if (stat (filename, &s) < 0 || s.st_size < 1024)
+  if (!filename || stat (filename, &s) < 0 || s.st_size < 1024)
filename = NULL;
 
   back_state = backtrace_create_state (filename, 1, error_callback, NULL);

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

[Samuel Thibault]

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
patches from Svante.

Samuel
Index: gcc/src/libgo/runtime/go-caller.c
===
--- gcc/src/libgo/runtime/go-caller.c   (révision 235086)
+++ gcc/src/libgo/runtime/go-caller.c   (copie de travail)
@@ -93,7 +93,7 @@
 argv[0] (http://gcc.gnu.org/PR61895).  It would be nice to
 have a better check for whether this file is the real
 executable.  */
-   if (stat (filename, &s) < 0 || s.st_size < 1024)
+   if (filename != NULL && (stat (filename, &s) < 0 || s.st_size < 1024))
filename = NULL;
 
   back_state = backtrace_create_state (filename, 1, error_callback, NULL);

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

[Samuel Thibault]

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
cc   test.o test-cuda.o  -lcudart -o test
/usr/bin/ld: test-cuda.o: relocation R_X86_64_32S against `.bss' can not be 
used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output

The attached archive shows this testcase: it just builds a test.o with
nvcc, and tries to link it with gcc, and that fails with the message
above.  This can be fixed by passing --compiler-options -fpie to nvcc,
but that's something that users will have a hard time understanding,
while it will be basically always needed in Stretch. So I'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, 'unstable-debug'), (500, 
'testing-debug'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'stable'), 
(500, 'oldstable'), (1, 'experimental-debug'), (1, 'buildd-experimental'), (1, 
'experimental')
Architecture: amd64
 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.11.0 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages nvidia-cuda-toolkit depends on:
ii  clang1:3.8-36
ii  clang-3.81:3.8.1-23
ii  g++-55.4.1-8
ii  gcc-55.4.1-8
ii  libc62.24-10
ii  libgcc1  1:7-20170407-1
ii  libnvvm3 8.0.44-3
ii  libstdc++6   7-20170407-1
ii  nvidia-cuda-dev  8.0.44-3
ii  nvidia-profiler  8.0.44-3
ii  ocl-icd-opencl-dev [opencl-dev]  2.2.11-1

Versions of packages nvidia-cuda-toolkit recommends:
pn  nvidia-cuda-doc 
ii  nvidia-cuda-gdb 8.0.44-3
ii  nvidia-visual-profiler  8.0.44-3

Versions of packages nvidia-cuda-toolkit suggests:
ii  libcupti-dev   8.0.44-3
pn  nvidia-driver  

-- no debconf information

-- 
Samuel
Fatal Error: Found [MS-Windows] System -> Repartitioning Disk for Linux...
(By cbbr...@io.org, Christopher Browne)


test.tgz
Description: application/gtar-compressed

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

[Samuel Thibault]

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 test-cuda.o  -lcudart -o test
> /usr/bin/ld: test-cuda.o: relocation R_X86_64_32S against `.bss' can not be 
> used when making a shared object; recompile with -fPIC
> /usr/bin/ld: final link failed: Nonrepresentable section on output

That said, it's the same issue with clang-3.8, see attached testcase:

cc-c -o test.o test.c
clang-3.8  -c test-clang.c -o test-clang.o
cc   test.o test-clang.o   -o test
/usr/bin/ld: test-clang.o: relocation R_X86_64_32S against undefined symbol `x' 
can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Nonrepresentable section on output

Samuel


test2.tgz
Description: application/gtar-compressed

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

[Samuel Thibault]

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 test-cuda.cu -o test-cuda.o
ERROR: No supported gcc/g++ host compiler found, but clang-3.8 is available.
   Use 'nvcc -ccbin clang-3.8' to use that instead.

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.

> I reproduced the failure you reported, but there is a simpler solution
> to the issue as shown below.
> 
> test$ CC=clang-3.8 make
> clang-3.8-c -o test.o test.c
> nvcc -ccbin clang-3.8 -c test-cuda.cu -o test-cuda.o
> clang-3.8   test.o test-cuda.o  -lcudart -o test

Ok, but that's still something difficult to the user to work out, while
it is needed for basically any use of nvcc. Currently NEWS.Debian.gz
only advises to use -ccbin clang-3.8.

> Maybe this is a bug about GCC's linking process on a set of GCC-6 and
> clang-3.8 produced objects.

> Clang-3.8 is able to link a set of mixed object files while GCC-6
> fails to do so. I guess
> this bug is a GCC-6 bug and not related to CUDA?

Well, AIUI it's not considered a bug to require PIE, but a toolchain
goal...

> On the other 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: nvidia-cuda-toolkit: nvcc needs to pass -fpie to compiler

[Samuel Thibault]

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 and binutils maintainers to get their opinion on this
:)

The problem is the move of some parts of the toolchain to pie by
default, without updating the whole toolchain. Whenever not using only
gcc for building object files, the issue shows up. nvcc is only an
example of this.

> And what can we do from the CUDA packaging side except for a new
> NEWS/README.Debian section?
> 
> I plan to point out these in the new NEWS/README.Debian section:
> (1) Try to compile the whole CUDA application with clang-3.8
> (2) Append the PIE/PIC flags 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

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

[Samuel Thibault]

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, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 
'proposed-updates'), (500, 'oldstable-proposed-updates-debug'), (500, 
'oldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), 
(500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.3.0 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gcc-9 depends on:
ii  binutils  2.32.51.20190821-2
ii  cpp-9 9.2.1-4
ii  gcc-9-base9.2.1-4
ii  libc6 2.29-1
ii  libcc1-0  9.2.1-4
ii  libgcc-9-dev  9.2.1-4
ii  libgcc1   1:9.2.1-4
ii  libgmp10  2:6.1.2+dfsg-4
ii  libisl19  0.20-2
ii  libmpc3   1.1.0-1
ii  libmpfr6  4.0.2-1
ii  libstdc++69.2.1-4
ii  zlib1g1:1.2.11.dfsg-1+b1

Versions of packages gcc-9 recommends:
ii  libc6-dev  2.29-1

Versions of packages gcc-9 suggests:
ii  gcc-9-doc 9.2.0-1
pn  gcc-9-locales 
ii  gcc-9-multilib9.2.1-4
pn  libasan5-dbg  
pn  libatomic1-dbg
pn  libgcc1-dbg   
pn  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: Samuel Thibault 
Date:   Thu Sep 12 08:53:23 2019 +0200

Disable gm2 on hurd-i386, mc hangs there

diff --git a/debian/changelog b/debian/changelog
index 3e4df82..7700fdb 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,9 +1,13 @@
 gcc-9 (9.2.1-9) UNRELEASED; urgency=medium
 
+  [ Matthias Klose ]
   * Update to SVN 20190917 (r275806) from the gcc-9-branch.
 - Fix PR libstdc++/91748, PR rtl-optimization/89795, PR c++/91705,
   PR fortran/91557, PR fortran/91553, PR fortran/91566, PR fortran/91642.
 
+  [ Samuel Thibault ]
+  * Disable gm2 on hurd-i386, mc hangs there.
+
  -- Matthias Klose   Tue, 17 Sep 2019 17:10:04 +0200
 
 gcc-9 (9.2.1-8) unstable; urgency=medium
diff --git a/debian/rules.defs b/debian/rules.defs
index 54bad2a..dca283d 100644
--- a/debian/rules.defs
+++ b/debian/rules.defs
@@ -1195,7 +1195,7 @@ ifneq ($(with_base_only),yes)
 with_m2 := yes
   endif
 endif
-m2_no_archs = powerpc ppc64 sh4 x32 kfreebsd-amd64 kfreebsd-i386
+m2_no_archs = powerpc ppc64 sh4 x32 kfreebsd-amd64 kfreebsd-i386 hurd-i386
 ifneq (,$(filter $(DEB_TARGET_ARCH),$(m2_no_archs)))
 with_m2 := disabled for cpu $(DEB_TARGET_ARCH)
 endif

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

[Samuel Thibault]

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 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

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

[Samuel Thibault]

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: Hurd port for gcc-7 go PATCH 1-3(15)

[Samuel Thibault]

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.

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

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

[Samuel Thibault]

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.

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'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.14.0 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gcc-7 depends on:
ii  binutils  2.29.1-12
ii  cpp-7 7.2.0-18
ii  gcc-7-base7.2.0-18
ii  libc6 2.25-3
ii  libcc1-0  8-20171102-1
ii  libgcc-7-dev  7.2.0-18
ii  libgcc1   1:8-20171102-1
ii  libgmp10  2:6.1.2+dfsg-1.1
ii  libisl15  0.18-1
ii  libmpc3   1.0.3-2
ii  libmpfr4  3.1.6-1
ii  libstdc++68-20171102-1
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages gcc-7 recommends:
ii  libc6-dev  2.25-3

Versions of packages gcc-7 suggests:
ii  gcc-7-doc 7.2.0-1
pn  gcc-7-locales 
ii  gcc-7-multilib7.2.0-18
pn  libasan4-dbg  
pn  libatomic1-dbg
pn  libcilkrts5-dbg   
pn  libgcc1-dbg   
pn  libgomp1-dbg  
pn  libitm1-dbg   
pn  liblsan0-dbg  
pn  libmpx2-dbg   
pn  libquadmath0-dbg  
pn  libtsan0-dbg  
pn  libubsan0-dbg 

-- no debconf information

-- 
Samuel
 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 vouloir dire ?
 N a eu la meme merde
 c ça que ça veut dire ? wow, c'est bien crypté :)
 -+- #ens-mim s'entraide -+-

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

[Samuel Thibault]

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 is attached.

AIUI, that is expected by gcc people: the gcc documentation says:

“to test whether the attribute referenced by its operand is recognized
by GCC”

Strictly speaking, being recognized by GCC doesn't mean being supported
on the target platform. I agree that it makes it not really useful
here, but I'm not the one to be convinced :) I'd say bring the issue to
upstream gcc.

Samuel

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

[Samuel Thibault]

Package: gcc-9
Version: 9.3.0-12
Severity: important
Tags: patch

Hello,

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 any issue.

This needs to be applied on gcc-10 and snapshot as 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, 'proposed-updates-debug'), (500, 
'proposed-updates'), (500, 'oldstable-proposed-updates-debug'), (500, 
'oldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), 
(500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.6.0-1-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gcc-9 depends on:
ii  binutils  2.34-5
ii  cpp-9 9.3.0-12
ii  gcc-9-base9.3.0-12
ii  libc6 2.30-8
ii  libcc1-0  10.1.0-1
ii  libgcc-9-dev  9.3.0-12
ii  libgcc-s1 10.1.0-1
ii  libgmp10  2:6.2.0+dfsg-4
ii  libisl22  0.22.1-1
ii  libmpc3   1.1.0-1
ii  libmpfr6  4.0.2-1
ii  libstdc++610.1.0-1
ii  zlib1g1:1.2.11.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:51:04 2020 +0200

debian/rules: Do not pass --with-arch=i586 on hurd-i386.

diff --git a/debian/rules2 b/debian/rules2
index bdb4657..c1ec236 100644
--- a/debian/rules2
+++ b/debian/rules2
@@ -595,10 +595,6 @@ ifeq ($(multilib),yes)
   CONFARGS += --enable-multilib
 endif
 
-ifneq (,$(filter $(DEB_TARGET_ARCH), hurd-i386))
-  CONFARGS += --with-arch=i586
-endif
-
 ifeq ($(DEB_TARGET_ARCH),lpia)
   CONFARGS += --with-arch=pentium-m --with-tune=i586
 endif

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

[Samuel Thibault]

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 any issue.
> 
> is it really correct to omit this configure option, instead of setting it to
> i686 explicitly?

i686 is already inherited from dpkg-architecture's output:

DEB_TARGET_GNU_CPU=i686
DEB_TARGET_GNU_SYSTEM=gnu
DEB_TARGET_GNU_TYPE=i686-gnu

(just like on linux-any and kfreebsd-any).

Samuel

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

[Samuel Thibault]

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 building with --with-arch=i586, while
> >>> there is no reason any more to do so. I checked building glibc, hurd,
> >>> gnumach, without any issue.
> >>
> >> is it really correct to omit this configure option, instead of setting it 
> >> to
> >> i686 explicitly?
> > 
> > i686 is already inherited from dpkg-architecture's output:
> > 
> > DEB_TARGET_GNU_CPU=i686
> > DEB_TARGET_GNU_SYSTEM=gnu
> > DEB_TARGET_GNU_TYPE=i686-gnu
> > 
> > (just like on linux-any and kfreebsd-any).
> 
> the TARGET macros are overridden because dpkg should not define the baseline.
> The target macros are also bogus in case a package builds for multiple 
> targets.
> 
> I'll set that directly.

I'm a bit lost as to why you seem to think something needs to be set
explicitly.

AIUI, for linux-i386 and kfreebsd-i386 nothing explicitly says to use
i686. I'm just saying that there is nothing to say for hurd-any either
(and certainly not request i586 which is an old remnant from previous
toolchains).

And I did try to use that compiler, it does produce i686 code, so it
does have the desired effect of just behaving like linux-any and
kfreebsd-any, instead of having a special case for hurd-any.

Samuel

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

[Samuel Thibault]

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 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.

[Samuel Thibault]

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#970614: gcc-10: Please disable systemtap-sdt-dev build-dep on non-Linux

[Samuel Thibault]

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 prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 
'proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), (500, 
'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental-debug'), 
(1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.8.0-1-amd64 (SMP w/8 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gcc-10 depends on:
ii  binutils   2.35-3
ii  cpp-10 10.2.0-7
ii  gcc-10-base10.2.0-7
ii  libc6  2.31-3
ii  libcc1-0   10.2.0-7
ii  libgcc-10-dev  10.2.0-7
ii  libgcc-s1  10.2.0-7
ii  libgmp10   2:6.2.0+dfsg-6
ii  libisl22   0.22.1-1
ii  libmpc31.2.0-1
ii  libmpfr6   4.1.0-3
ii  libstdc++6 10.2.0-7
ii  libzstd1   1.4.5+dfsg-4
ii  zlib1g 1:1.2.11.dfsg-2

Versions of packages gcc-10 recommends:
ii  libc6-dev  2.31-3

Versions of packages gcc-10 suggests:
ii  gcc-10-doc   10.1.0-1
pn  gcc-10-locales   
ii  gcc-10-multilib  10.2.0-7

-- no debconf information

-- 
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 systemtap-sdt-dev build dependency to linux architectures

diff --git a/debian/changelog b/debian/changelog
index e22f761..af94789 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+gcc-10 (10.2.0-10) UNRELEASED; urgency=high
+
+  * Limit systemtap-sdt-dev build dependency to linux architectures.
+
+ -- Samuel Thibault   Sat, 19 Sep 2020 13:24:24 +0200
+
 gcc-10 (10.2.0-9) unstable; urgency=high
 
   * Update to git 20200918 from the gcc-10 branch.
diff --git a/debian/control b/debian/control
index 2f83de6..34fc359 100644
--- a/debian/control
+++ b/debian/control
@@ -10,7 +10,7 @@ Build-Depends: debhelper (>= 9.20141010), dpkg-dev (>= 
1.17.14), g++-multilib [a
   m4, libtool, autoconf, 
   dwz, libunwind8-dev [ia64], libatomic-ops-dev [ia64], 
   gawk, lzma, xz-utils, patchutils, 
-  libzstd-dev, zlib1g-dev, systemtap-sdt-dev [linux-any kfreebsd-any 
hurd-any], 
+  libzstd-dev, zlib1g-dev, systemtap-sdt-dev [linux-any], 
   binutils:native (>= 2.35), binutils-hppa64-linux-gnu:native (>= 2.35) [hppa 
amd64 i386 x32], 
   gperf (>= 3.0.1), bison (>= 1:2.3), flex, gettext, 
   gdb:native [!riscv64], nvptx-tools [amd64 ppc64el], llvm-10 [amd64], lld-10 
[amd64], 
diff --git a/debian/rules.conf b/debian/rules.conf
index 8667ea0..75c8cca 100644
--- a/debian/rules.conf
+++ b/debian/rules.conf
@@ -443,7 +443,7 @@ endif
 AUTO_BUILD_DEP += autoconf$(autoconf_version),
 
 ifeq (,$(filter $(distrelease),lenny etch squeeze wheezy dapper hardy jaunty 
karmic lucid maverick natty oneiric precise quantal raring saucy trusty))
-  SDT_BUILD_DEP = systemtap-sdt-dev [linux-any kfreebsd-any hurd-any],
+  SDT_BUILD_DEP = systemtap-sdt-dev [linux-any],
 endif
 
 # ensure that the common libs, built from the next GCC version are available

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

[Samuel Thibault]

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?
> 
> Have you seen #969968?

Ah, no, since systemtap is a Linux thing I didn't bother looking at it.

Is it really useful to try to maintain systemtap building on non-Linux
arch, since AIUI it's Linux-only?

> Maybe you can NMU that package, or build it for -ports until upstream
> or the Debian maintainer has reacted.

I have uploaded to hurd's ports only, since the patches look
non-trivial.

Samuel

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

[Samuel Thibault]

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, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 
'proposed-updates-debug'), (500, 'proposed-updates'), (500, 
'oldstable-proposed-updates'), (500, 'oldoldstable'), (500, 'buildd-unstable'), 
(500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 6.2.0 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gcc-13 depends on:
ii  binutils   2.40-2
ii  cpp-13 13.1.0-1
ii  gcc-13-base13.1.0-1
ii  libc6  2.36-9
ii  libcc1-0   13.1.0-1
ii  libgcc-13-dev  13.1.0-1
ii  libgcc-s1  13.1.0-1
ii  libgmp10   2:6.2.1+dfsg1-1.1
ii  libisl23   0.25-1
ii  libmpc31.3.1-1
ii  libmpfr6   4.2.0-1
ii  libstdc++6 13.1.0-1
ii  libzstd1   1.5.4+dfsg2-5
ii  zlib1g 1:1.2.13.dfsg-1

Versions of packages gcc-13 recommends:
ii  libc6-dev  2.36-9

Versions of packages gcc-13 suggests:
pn  gcc-13-doc   
pn  gcc-13-locales   
pn  gcc-13-multilib  

-- no debconf information

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.
diff --git a/debian/control b/debian/control
index 0555ad8..f131d68 100644
--- a/debian/control
+++ b/debian/control
@@ -5,7 +5,7 @@ Maintainer: Debian GCC Maintainers 
 Uploaders: Matthias Klose 
 Standards-Version: 4.6.2
 Build-Depends: debhelper (>= 9.20141010), dpkg-dev (>= 1.17.14), g++-multilib 
[amd64 i386 kfreebsd-amd64 mips mips64 mips64el mips64r6 mips64r6el mipsel 
mipsn32 mipsn32el mipsn32r6 mipsn32r6el mipsr6 mipsr6el powerpc ppc64 s390 
s390x sparc sparc64 x32] , 
-  libc6.1-dev (>= 2.23-1~) [alpha ia64] | libc0.3-dev (>= 2.23-1~) [hurd-i386] 
| libc0.1-dev (>= 2.25) [kfreebsd-i386 kfreebsd-amd64] | libc6-dev (>= 
2.23-1~), libc6-dev-amd64 [i386 x32], libc6-dev-sparc64 [sparc], 
libc6-dev-sparc [sparc64], libc6-dev-s390 [s390x], libc6-dev-s390x [s390], 
libc6-dev-i386 [amd64 x32], libc6-dev-powerpc [ppc64], libc6-dev-ppc64 
[powerpc], libc0.1-dev-i386 [kfreebsd-amd64], lib32gcc-s1 [amd64 ppc64 
kfreebsd-amd64 mipsn32 mipsn32el mips64 mips64el mipsn32r6 mipsn32r6el mips64r6 
mips64r6el s390x sparc64 x32], libn32gcc-s1 [mips mipsel mips64 mips64el mipsr6 
mipsr6el mips64r6 mips64r6el], lib64gcc-s1 [i386 mips mipsel mipsn32 mipsn32el 
mipsr6 mipsr6el mipsn32r6 mipsn32r6el powerpc sparc s390 x32], libc6-dev-mips64 
[mips mipsel mipsn32 mipsn32el mipsr6 mipsr6el mipsn32r6 mipsn32r6el], 
libc6-dev-mipsn32 [mips mipsel mips64 mips64el mipsr6 mipsr6el mips64r6 
mips64r6el], libc6-dev-mips32 [mipsn32 mipsn32el mips64 mips64el mipsn32r6 
mipsn32r6el mips64r6 mips64r6el], libc6-dev-x32 [amd64 i386], libx32gcc-s1 
[amd64 i386], libc6.1-dbg [alpha ia64] | libc0.3-dbg [hurd-i386] | libc0.1-dbg 
[kfreebsd-i386 kfreebsd-amd64] | libc6-dbg, 
+  libc6.1-dev (>= 2.23-1~) [alpha ia64] | libc0.3-dev (>= 2.23-1~) [hurd-amd64 
hurd-i386] | libc0.1-dev (>= 2.25) [kfreebsd-i386 kfreebsd-amd64] | libc6-dev 
(>= 2.23-1~), libc6-dev-amd64 [i386 x32], libc6-dev-sparc64 [sparc], 
libc6-dev-sparc [sparc64], libc6-dev-s390 [s390x], libc6-dev-s390x [s390], 
libc6-dev-i386 [amd64 x32], libc6-dev-powerpc [ppc64], libc6-dev-ppc64 
[powerpc], libc0.1-dev-i386 [kfreebsd-amd64], lib32gcc-s1 [amd64 ppc64 
kfreebsd-amd64 mipsn32 mipsn32el mips64 mips64el mipsn32r6 mipsn32r6el mips64r6 
mips64r6el s390x sparc64 x32], libn32gcc-s1 [mips mipsel mips64 mips64el mipsr6 
mipsr6el mips64r6 mips64r6el], lib64gcc-s1 [i386 mips mipsel mipsn32 mipsn32el 
mipsr6 mipsr6el mipsn32r6 mipsn32r6el powerpc sparc s390 x32], libc6-dev-mips64 
[mips mipsel mipsn32 mipsn32el mipsr6 mipsr6el mipsn32r6 mipsn32r6el], 
libc6-dev-mipsn32 [mips mipsel mips64 mips64el mipsr6 mipsr6el mips64r6 
mips64r6el], libc6-dev-mips32 [mipsn32 mipsn32el mips64 mips64el mipsn32r6 
mipsn32r6el mips64r6 mips64r6el], libc6-dev-x32 [amd64 i386], libx32gcc-s1 
[amd64 i386], libc6.1-dbg [alpha ia64] | libc0.3-dbg [hurd-amd64 hurd-i386] | 
libc0.1-dbg [kfreebsd-i386 kfreebsd-amd64] | libc6-dbg, 
   kfreebsd-kernel-headers (>= 0.84) [kfreebsd-any], linux-libc-dev [m68k], 
   m4, libtool, aut

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

[Samuel Thibault]

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
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. glib2.0.

Samuel

-- System Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 
'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 
'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 
'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500, 
'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 6.3.0 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libelf-dev depends on:
ii  libelf1 0.188-2.1
ii  zlib1g-dev  1:1.2.13.dfsg-1

libelf-dev recommends no packages.

libelf-dev suggests no packages.

-- no debconf information

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.
--- debian/control.original 2023-07-02 02:27:55.928634126 +0200
+++ debian/control  2023-07-02 02:28:07.188696284 +0200
@@ -53,7 +53,7 @@
 Section: libdevel
 Architecture: any
 Multi-Arch: same
-Depends: libelf1 (= ${binary:Version}), ${misc:Depends}, zlib1g-dev
+Depends: libelf1 (= ${binary:Version}), ${misc:Depends}, zlib1g-dev, 
libzstd-dev
 Conflicts: libelfg0-dev
 Description: libelf1 development libraries and header files
  libelf1 provides a shared library which allows reading and writing of ELF

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

[Samuel Thibault]

Package: gcc-13
Version: 13.2.0-7
Severity: important
Tags: patch
X-Debbugs-Cc: debian-h...@lists.debian.org
User: debian-h...@lists.debian.org
Usertags: hurd

Hello,

The attached patch adds support for hurd-amd64, could you apply it?

The part in hurd-amd64.diff comes from the upstream master 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 policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'unreleased'), 
(500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 
'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 
'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500, 
'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 6.5.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gcc-13 depends on:
ii  binutils   2.41-7
ii  cpp-13 13.2.0-7
ii  gcc-13-base13.2.0-7
ii  libc6  2.37-12+b1
ii  libcc1-0   13.2.0-7
ii  libgcc-13-dev  13.2.0-7
ii  libgcc-s1  13.2.0-7
ii  libgmp10   2:6.3.0+dfsg-2
ii  libisl23   0.26-3
ii  libmpc31.3.1-1
ii  libmpfr6   4.2.1-1
ii  libstdc++6 13.2.0-7
ii  libzstd1   1.5.5+dfsg2-2
ii  zlib1g 1:1.2.13.dfsg-3

Versions of packages gcc-13 recommends:
ii  libc6-dev  2.37-12+b1

Versions of packages gcc-13 suggests:
ii  gcc-13-doc   13.2.0-1
pn  gcc-13-locales   
ii  gcc-13-multilib  13.2.0-7

-- no debconf information

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.
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 2023 +0200
+
+hurd: Add multilib paths for gnu-x86_64
+
+We need the multilib paths in gcc to find e.g. glibc crt files on
+Debian.  This is essentially based on t-linux64 version.
+
+gcc/ChangeLog:
+
+* config/i386/t-gnu64: New file.
+* config.gcc [x86_64-*-gnu*]: Add i386/t-gnu64 to
+tmake_file.
+
+commit c768917402d4cba69a92c737e56e177f5b8ab0df
+Author: Samuel Thibault 
+Date:   Sat May 6 13:55:44 2023 +0200
+
+hurd: Ad default-pie and static-pie support
+
+This fixes the Hurd spec in the default-pie case, and adds static-pie
+support.
+
+gcc/ChangeLog:
+
+* config/i386/gnu.h: Use PIE_SPEC, add static-pie case.
+* config/i386/gnu64.h: Use PIE_SPEC, add static-pie case.
+
+diff --git a/src/gcc/config.gcc b/src/gcc/config.gcc
+index 3000379cafc..e62849c1230 100644
+--- a/src/gcc/config.gcc
 b/src/gcc/config.gcc
+@@ -5973,6 +5973,9 @@ case ${target} in
+   visium-*-*)
+   target_cpu_default2="TARGET_CPU_$with_cpu"
+   ;;
++  x86_64-*-gnu*)
++  tmake_file="$tmake_file i386/t-gnu64"
++  ;;
+ esac
+ 
+ t=
+diff --git a/src/gcc/config/i386/t-gnu64 b/src/gcc/config/i386/t-gnu64
+new file mode 100644
+index 000..23ee6823d65
+--- /dev/null
 b/src/gcc/config/i386/t-gnu64
+@@ -0,0 +1,38 @@
++# Copyright (C) 2002-2023 Free Software Foundation, Inc.
++#
++# This file is part of GCC.
++#
++# GCC is free software; you can redistribute it and/or modify
++# it under the terms of the GNU General Public License as published by
++# the Free Software Foundation; either version 3, or (at your option)
++# any later version.
++#
++# GCC is distributed in the hope that it will be useful,
++# but WITHOUT ANY WARRANTY; without even the implied warranty of
++# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
++# GNU General Public License for more details.
++#
++# You should have received a copy of the GNU General Public License
++# along with GCC; see the file COPYING3.  If not see
++# <http://www.gnu.org/licenses/>.
++
++# On Debian, Ubuntu and other derivative distributions, the 32bit libraries
++# are found in /lib32 and /usr/lib32, /lib64 and /usr/lib64 are sym

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

[Samuel Thibault]

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 (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, 'testing'), (500, 'unstable-debug'), (500, 'unreleased'), 
(500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 
'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 
'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500, 
'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 6.7.0 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gcc-13 depends on:
ii  binutils 2.42-2
ii  gcc-13-base  13.2.0-13
ii  gcc-13-x86-64-linux-gnu  13.2.0-13

Versions of packages gcc-13 recommends:
ii  libc6-dev  2.37-15~deb13u1

Versions of packages gcc-13 suggests:
ii  gcc-13-doc   13.2.0-1
pn  gcc-13-locales   
ii  gcc-13-multilib  13.2.0-13

-- no debconf information

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.
diff --git a/debian/rules.defs b/debian/rules.defs
index 8638be92..4fa62c62 100644
--- a/debian/rules.defs
+++ b/debian/rules.defs
@@ -1019,41 +1019,41 @@ endif
 
 go_no_cpus := arc avr hppa loong64
 go_no_cpus += m68k # See PR 79281 / PR 83314
 go_no_systems := kfreebsd-gnu
 ifneq (,$(filter $(distrelease),precise))
   go_no_cpus  = armhf
   go_no_archs = armhf
 endif
 # Debian #969221
 go_no_cpus  += sh4
 go_no_archs += sh4
 
 ifneq ($(with_base_only),yes)
   ifneq ($(separate_lang),yes)
 with_go := yes
   endif
 endif
 ifneq (,$(filter $(DEB_TARGET_ARCH_CPU),$(go_no_cpus)))
   with_go := disabled for cpu $(DEB_TARGET_ARCH_CPU)
 endif
-ifneq (,$(findstring $(DEB_TARGET_ARCH_OS),$(go_no_systems)))
+ifneq (,$(findstring $(DEB_TARGET_GNU_SYSTEM),$(go_no_systems)))
   with_go := disabled for system $(DEB_TARGET_GNU_SYSTEM)
 endif
 ifneq (,$(filter $(DEB_TARGET_ARCH),$(go_no_archs)))
   with_go := disabled for architecture $(DEB_TARGET_ARCH)
 endif
 ifeq ($(go_no_cross)-$(DEB_CROSS),yes-yes)
   with_go := disabled for cross compiler package
 endif
 ifeq ($(DEB_STAGE)-$(filter libgo, $(with_rtlibs)),rtlibs-)
   with_go := disabled for rtlibs stage
 endif
 with_go := $(call envfilt, go, , , $(with_go))
 
 # Build all packages needed for Go development
 ifneq (,$(findstring gcc, $(PKGSOURCE)))
   ifeq ($(with_go),yes)
 ifeq ($(with_dev),yes)
   with_godev := yes
 endif
 with_libgo := yes
@@ -1262,41 +1262,41 @@ endif
 with_objcxx := $(call envfilt, obj-c++, , c++ objc, $(with_objcxx))
 
 ifeq ($(with_objcxx),yes)
   enabled_languages += obj-c++
 endif
 
 # Modula-2 ---
 m2_no_cross := yes
 m2_no_cross := no
 
 ifneq ($(with_base_only),yes)
   ifneq ($(separate_lang),yes)
 with_m2 := yes
   endif
 endif
 m2_no_cpus = loong64 powerpc ppc64 sh4
 m2_no_systems = gnu kfreebsd-gnu
 ifneq (,$(filter $(DEB_TARGET_ARCH_CPU),$(m2_no_cpus)))
 with_m2 := disabled for cpu $(DEB_TARGET_ARCH_CPU)
 endif
-ifneq (,$(findstring $(DEB_TARGET_ARCH_OS),$(m2_no_systems)))
+ifneq (,$(findstring $(DEB_TARGET_GNU_SYSTEM),$(m2_no_systems)))
   with_m2 := disabled for system $(DEB_TARGET_GNU_SYSTEM)
 endif
 ifeq ($(m2_no_cross)-$(DEB_CROSS),yes-yes)
   with_m2 := disabled for cross compiler package
 endif
 ifeq ($(DEB_STAGE)-$(filter libgm2, $(with_rtlibs)),rtlibs-)
   with_m2 := disabled for rtlibs stage
 endif
 ifneq (,$(filter $(distrelease),precise))
   with_m2 := disabled for $(distrelease) backport
 endif
 #with_m2 := disabled for GCC 13
 
 with_m2 := $(call envfilt, m2, , , $(with_m2))
 
 # Build all packages needed for Modula-2 development
 ifeq ($(with_m2),yes)
   ifeq ($(with_dev),yes)
 with_m2dev := yes
   endif

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

[Samuel Thibault]

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 (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, 'testing'), (500, 'unstable-debug'), (500, 'unreleased'), 
(500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 
'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 
'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500, 
'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 6.7.0 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.
diff --git a/debian/rules.defs b/debian/rules.defs
index 2810b233..1bb4b96e 100644
--- a/debian/rules.defs
+++ b/debian/rules.defs
@@ -989,7 +989,7 @@ endif
 ifneq (,$(filter $(DEB_TARGET_ARCH),$(go_no_cpus)))
   with_go := disabled for arch $(DEB_TARGET_ARCH)
 endif
-ifneq (,$(findstring $(DEB_TARGET_ARCH_OS),$(go_no_systems)))
+ifneq (,$(findstring $(DEB_TARGET_GNU_SYSTEM),$(go_no_systems)))
   with_go := disabled for system $(DEB_TARGET_GNU_SYSTEM)
 endif
 ifeq ($(go_no_cross)-$(DEB_CROSS),yes-yes)
@@ -1189,7 +1189,7 @@ n2_no_systems = gnu
 ifneq (,$(filter $(DEB_TARGET_ARCH_CPU),$(m2_no_cpus)))
   with_m2 := disabled for cpu $(DEB_TARGET_ARCH_CPU)
 endif
-ifneq (,$(findstring $(DEB_TARGET_ARCH_OS),$(m2_no_systems)))
+ifneq (,$(findstring $(DEB_TARGET_GNU_SYSTEM),$(m2_no_systems)))
   with_m2 := disabled for system $(DEB_TARGET_GNU_SYSTEM)
 endif
 ifeq ($(m2_no_cross)-$(DEB_CROSS),yes-yes)

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

[Samuel Thibault]

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 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.

Actually in the gcc-14 case there was another typo, updated patch
attached.

Samuel
diff --git a/debian/rules.defs b/debian/rules.defs
index 2810b233..6ef02c98 100644
--- a/debian/rules.defs
+++ b/debian/rules.defs
@@ -989,7 +989,7 @@ endif
 ifneq (,$(filter $(DEB_TARGET_ARCH),$(go_no_cpus)))
   with_go := disabled for arch $(DEB_TARGET_ARCH)
 endif
-ifneq (,$(findstring $(DEB_TARGET_ARCH_OS),$(go_no_systems)))
+ifneq (,$(findstring $(DEB_TARGET_GNU_SYSTEM),$(go_no_systems)))
   with_go := disabled for system $(DEB_TARGET_GNU_SYSTEM)
 endif
 ifeq ($(go_no_cross)-$(DEB_CROSS),yes-yes)
@@ -1185,11 +1185,11 @@ ifneq ($(with_base_only),yes)
   endif
 endif
 m2_no_cpus = loong64 powerpc ppc64 sh4
-n2_no_systems = gnu
+m2_no_systems = gnu
 ifneq (,$(filter $(DEB_TARGET_ARCH_CPU),$(m2_no_cpus)))
   with_m2 := disabled for cpu $(DEB_TARGET_ARCH_CPU)
 endif
-ifneq (,$(findstring $(DEB_TARGET_ARCH_OS),$(m2_no_systems)))
+ifneq (,$(findstring $(DEB_TARGET_GNU_SYSTEM),$(m2_no_systems)))
   with_m2 := disabled for system $(DEB_TARGET_GNU_SYSTEM)
 endif
 ifeq ($(m2_no_cross)-$(DEB_CROSS),yes-yes)

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

[Samuel Thibault]

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 Information:
Debian Release: trixie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable-debug'), (500, 'unreleased'), 
(500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 
'oldstable-proposed-updates-debug'), (500, 'oldstable-proposed-updates'), (500, 
'oldoldstable-proposed-updates'), (500, 'oldoldstable'), (500, 
'buildd-unstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 
'experimental-debug'), (1, 'buildd-experimental'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64

Kernel: Linux 6.7.0 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- 
Samuel
---
Pour une évaluation indépendante, transparente et rigoureuse !
Je soutiens la Commission d'Évaluation de l'Inria.
diff --git a/debian/rules.defs b/debian/rules.defs
index 928d4e56..44f3f3a0 100644
--- a/debian/rules.defs
+++ b/debian/rules.defs
@@ -1195,7 +1195,7 @@ ifneq ($(with_base_only),yes)
   endif
 endif
 m2_no_cpus = loong64 powerpc ppc64 sh4
-m2_no_systems = gnu
+m2_no_systems = 
 ifneq (,$(filter $(DEB_TARGET_ARCH_CPU),$(m2_no_cpus)))
   with_m2 := disabled for cpu $(DEB_TARGET_ARCH_CPU)
 endif

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

[Samuel Thibault]

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!

Samuel

Bug#893676: hurd: internal compiler error building petsc

[Samuel Thibault]

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)(~(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

Bug#893676: hurd: internal compiler error building petsc

[Samuel Thibault]

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:
> > > 
> > > 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)(~(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.
> 
> gcc-7 7.2.0-19 is built.

The current version of gcc-7 is 7.3.0-12

> Does it mean it's not compatible with MPFR ?

The old version, possibly yes.

Samuel

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

[Samuel Thibault]

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#1073830: gcc-14: Missing build dependency on cargo on hurd-i386

[Samuel Thibault]

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 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-dev (>= 1.17.14), 
g++-multilib [amd64 i38
   gperf, bison, flex,
   gettext, nvptx-tools [amd64 arm64 ppc64el], amdgcn-tools-18 [amd64],
   texinfo, locales-all, sharutils,
-  procps, gnat-13:native [!sparc !loong64], g++-13:native [!loong64], 
gnat-13:native [loong64], g++-14:native [loong64], netbase, gdc-13:native [!arc 
!ia64 !m68k !sh4 !s390 !sparc64 !alpha !hurd-alpha !hurd-amd64 !hurd-i386], 
python3:any, cargo [!hppa !ia64 !m68k !sh4 !alpha !hurd-alpha !hurd-amd64 
!hurd-i386],
+  procps, gnat-13:native [!sparc !loong64], g++-13:native [!loong64], 
gnat-13:native [loong64], g++-14:native [loong64], netbase, gdc-13:native [!arc 
!ia64 !m68k !sh4 !s390 !sparc64 !alpha !hurd-alpha !hurd-amd64 !hurd-i386], 
python3:any, cargo [!hppa !ia64 !m68k !sh4 !alpha !hurd-alpha],
   libisl-dev (>= 0.20), libmpc-dev (>= 1.0), libmpfr-dev (>= 3.0.0-9~), 
libgmp-dev (>= 2:5.0.1~), lib32z1-dev [amd64], lib64z1-dev [i386], unzip 
,
   dejagnu , coreutils, chrpath, lsb-release, quilt, time,
   pkg-config, libgc-dev,
diff --git a/debian/rules.defs b/debian/rules.defs
index 57a4b8ec..dbaf7f0f 100644
--- a/debian/rules.defs
+++ b/debian/rules.defs
@@ -1235,7 +1235,7 @@ endif
 rs_no_cross := yes
 
 rs_no_cpus = alpha hppa ia64 m68k sh4
-rs_no_systems := gnu
+rs_no_systems := 
 
 ifneq ($(with_base_only),yes)
   ifneq ($(separate_lang),yes)
@@ -1245,6 +1245,9 @@ endif
 ifneq (,$(filter $(DEB_TARGET_ARCH_CPU),$(rs_no_cpus)))
 with_rs := disabled for arch $(DEB_TARGET_ARCH_CPU)
 endif
+ifneq (,$(findstring $(DEB_TARGET_GNU_SYSTEM),$(rs_no_systems)))
+  with_rs := disabled for system $(DEB_TARGET_GNU_SYSTEM)
+endif
 ifeq ($(rs_no_cross)-$(DEB_CROSS),yes-yes)
   with_rs := disabled for cross compiler package
 endif

Bug#148529: gnat-3.1: sin/cos is random exception/result generator

[Samuel Tardieu]

>>>>> "Brian" == Brian May <[EMAIL PROTECTED]> writes:

Brian> raised CONSTRAINT_ERROR : s-imgrea.adb:236

Brian> (which is funny in a way, I don't see where this function is
Brian> getting called)

The package System.Img_Real is used to convert floats to string. You
can look at the expanded GNAT output using:

% gcc-3.1 -gnatds testbug2.adb

Brian> I find it really troubling that commenting out the last two
Brian> lines causes it to crash on the first line, and until it is
Brian> fixed, I consider the compiler to be badly broken.

Well, it looks like it is a i386 specific problem, as it works just
fine on Sparc. I get the same result as the one you give as correct in
your mail.

Brian> ...however both versions of the compiler seem to be buggy, as
Brian> reported in my other bug reports (bug #147145 applies to both
Brian> versions).

Brian> Is the quality of the Gnat compiler likely to improve any time
Brian> in the not-too-distant future, or should I be concentrating my
Brian> efforts for the moment at least on other languages?

The GNAT compiler based on GCC 2.8.1 is a top quality compiler. There
are some glitches in the GCC 3.1 port though.

  Sam
-- 
Samuel Tardieu -- [EMAIL PROTECTED]



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#148529: gnat-3.1: sin/cos is random exception/result generator

[Samuel Tardieu]

On  3/06, Brian May wrote:

| However, when I copied the routine to my code, it instantly stopped
| working at all (it turned the Asm call into a NOP), and I half suspected
| at the time that maybe I was doing something wrong (do I need to use a
| special compiler flag or something to get Asm code to work?).

No. You can check that your assembler has been properly included by
looking at the resulting assembly code (gcc-3.1 -S -o - testbug2.adb).

  Sam



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#170352: GNAT 4.1 issues a warning

[Samuel Tardieu]

fixed 170352 4.1.2-17
close 170352
thanks

GNAT 4.1 properly issues the warning.

Bug#123468: Autodesk 3D Studlo Max 9 for XP 149, Retails @ 6720 (u save 6590)

[Samuel Gardner]

adobe contribute cs3 - 39
ulead mediastudio pro v8.0 with extras - 79
symantec norton antivirus 10.1 for mac - 29
avid newscutter xp 6.7.2 - 69
adobe acrobat 8.0 professional - 79
zend studio - 49
adobe acrobat 3d - 59
propellerhead reason 3 - 69

type "kunchakoem . net" in your |nternet Explorer

steinberg wavelab 5.01a - 49
2007microsoft office enterprise - 79
intuit quicken home and business 2008 - 39
symantec norton antivirus 10.1 for mac - 29
final draft 7 - 39
ms windows 2003 enterprise server - 69
ms windows 2003 enterprise server - 69
ms xp professional with sp2 - 49
steinberg wavelab 5.01a - 49



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#472334: gcc-4.3: FTBFS on hurd-i386 because of symbol list

[Samuel Thibault]

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.772865000 +
+++ dpkg-gensymbolsFGx4wG   2008-03-23 13:51:10.772865000 +
@@ -432,10 +432,12 @@
  [EMAIL PROTECTED] 4.3
  [EMAIL PROTECTED] 4.3
  [EMAIL PROTECTED] 4.3
+ [EMAIL PROTECTED] 4.3.0-1
  [EMAIL PROTECTED] 4.3
  [EMAIL PROTECTED] 4.3
  [EMAIL PROTECTED] 4.3
  [EMAIL PROTECTED] 4.3
+ [EMAIL PROTECTED] 4.3.0-1
  [EMAIL PROTECTED] 4.1.1-21
  [EMAIL PROTECTED] 4.1.1-21
  [EMAIL PROTECTED] 4.1.1-21
@@ -1212,8 +1214,10 @@
  [EMAIL PROTECTED] 4.1.1-21
  [EMAIL PROTECTED] 4.1.1-21
  [EMAIL PROTECTED] 4.1.1-21
- [EMAIL PROTECTED] 4.1.1-21
- [EMAIL PROTECTED] 4.1.1-21
+ [EMAIL PROTECTED] 4.3.0-1
+#MISSING: 4.3.0-1# [EMAIL PROTECTED] 4.1.1-21
+ [EMAIL PROTECTED] 4.3.0-1
+#MISSING: 4.3.0-1# [EMAIL PROTECTED] 4.1.1-21
  [EMAIL PROTECTED] 4.1.1-21
  [EMAIL PROTECTED] 4.1.1-21
  [EMAIL PROTECTED] 4.1.1-21
dh_makeshlibs: command returned error code 256

I guess that the
  [EMAIL PROTECTED] 4.3.0-1
  [EMAIL PROTECTED] 4.3.0-1
symbols could just be added to libstdc++6.symbols.hurd-i386, but for the
__pthread_mutex/pthread_mutex_t difference we will probably have to move
them to linux/hurd-specific files.

(I guess the difference is due to hurd-i386 using
typedef struct __pthread_mutex pthread_mutex_t; 
in its pthread.h)

Samuel

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.18.8-xen (SMP w/1 CPU core)
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/bash

Versions of packages gcc-4.3 depends on:
ii  binutils2.18.1~cvs20080103-1 The GNU assembler, linker and bina
ii  cpp-4.3 4.3.0-1  The GNU C preprocessor
ii  gcc-4.3-base4.3.0-1  The GNU Compiler Collection (base 
ii  libc6   2.7-6GNU C Library: Shared libraries
ii  libgcc1 1:4.3.0-1GCC support library
ii  libgomp14.3.0-1  GCC OpenMP (GOMP) support library

Versions of packages gcc-4.3 recommends:
ii  libc6-dev 2.7-6  GNU C Library: Development Librari

-- no debconf information

-- 
Samuel
Now I know someone out there is going to claim, "Well then, UNIX is intuitive,
because you only need to learn 5000 commands, and then everything else follows
from that! Har har har!"
(Andy Bates in comp.os.linux.misc, on "intuitive interfaces", slightly
defending Macs.)



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#472334: gcc-4.3: FTBFS on hurd-i386 because of symbol list

[Samuel Thibault]

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:
> 
> please recheck with updated files in the packaging repository.

Compiles fine, thanks!

Samuel



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#483609: gcc-4.1: on hurd-i386 -fstack-protector tries to link with libssp_nonshared

[Samuel Thibault]

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 GNU/kfreebsd) __stack_chk_fail is available from glibc.

Cheers,
Samuel

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.25
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/bash

Versions of packages gcc-4.1 depends on:
ii  binutils2.18.1~cvs20080103-4 The GNU assembler, linker and bina
ii  cpp-4.1 4.1.2-19 The GNU C preprocessor
ii  gcc-4.1-base4.1.2-19 The GNU Compiler Collection (base 
ii  libc6   2.7-10   GNU C Library: Shared libraries
ii  libgcc1 1:4.3.0-3GCC support library

Versions of packages gcc-4.1 recommends:
ii  libc6-dev 2.7-10 GNU C Library: Development Librari
pn  libmudflap0-dev(no description available)

-- no debconf information

-- 
Samuel
"...[Linux's] capacity to talk via any medium except smoke signals."
(By Dr. Greg Wettstein, Roger Maris Cancer Center)
Index: debian/patches/libssp-gnu.dpatch
===
--- debian/patches/libssp-gnu.dpatch(révision 3128)
+++ debian/patches/libssp-gnu.dpatch(copie de travail)
@@ -36,7 +36,7 @@
  # Test for stack protector support in target C library.
  case "$target" in
 -  *-*-linux*)
-+  *-*-*-gnu*)
++  *-*-gnu*|*-*-*-gnu*)
  AC_CACHE_CHECK(__stack_chk_fail in target GNU C library,
gcc_cv_libc_provides_ssp,
[gcc_cv_libc_provides_ssp=no

Bug#483612: gcc-4.2: on hurd-i386 -fstack-protector tries to link with libssp_nonshared

[Samuel Thibault]

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 GNU/kfreebsd) __stack_chk_fail is available from glibc.

Cheers,
Samuel

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.25
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/bash

Versions of packages gcc-4.2 depends on:
ii  binutils2.18.1~cvs20080103-4 The GNU assembler, linker and bina
ii  cpp-4.2 4.2.3-5  The GNU C preprocessor
ii  gcc-4.2-base4.2.3-5  The GNU Compiler Collection (base 
ii  libc6   2.7-10   GNU C Library: Shared libraries
ii  libgcc1 1:4.3.0-3GCC support library

Versions of packages gcc-4.2 recommends:
ii  libc6-dev 2.7-10 GNU C Library: Development Librari

-- no debconf information

-- 
Samuel
...
 et Ctrl alt F2 pour aller sous console
 mais c koi pour passer d'un bureau a un autre !
 au fait c koi le raccourci pour passer d'un bureau a un autre 'question 
stupide"
 ça dépend du window manager et de ta conf
 ce qui fonctionne toujours c'est CTRL-ALT-BCKSP
-:- SignOff rv_: #linuxfr (Read error: EOF from client)
-:- rv_ [EMAIL PROTECTED] has joined #linuxfr
 Firebird: MEURT...
Index: debian/patches/libssp-gnu.dpatch
===
--- debian/patches/libssp-gnu.dpatch(révision 3128)
+++ debian/patches/libssp-gnu.dpatch(copie de travail)
@@ -34,7 +34,7 @@
  # Test for stack protector support in target C library.
  case "$target" in
 -  *-*-linux*)
-+  *-*-*-gnu*)
++  *-*-gnu*|*-*-*-gnu*)
  echo "$as_me:$LINENO: checking __stack_chk_fail in target GNU C library" 
>&5
  echo $ECHO_N "checking __stack_chk_fail in target GNU C library... $ECHO_C" 
>&6
  if test "${gcc_cv_libc_provides_ssp+set}" = set; then
@@ -45,7 +45,7 @@
  # Test for stack protector support in target C library.
  case "$target" in
 -  *-*-linux*)
-+  *-*-*-gnu*)
++  *-*-gnu*|*-*-*-gnu*)
  AC_CACHE_CHECK(__stack_chk_fail in target GNU C library,
gcc_cv_libc_provides_ssp,
[gcc_cv_libc_provides_ssp=no

Bug#483613: gcc-4.3: on hurd-i386 -fstack-protector tries to link with libssp_nonshared

[Samuel Thibault]

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 GNU/kfreebsd) __stack_chk_fail is available from glibc.

Cheers,
Samuel

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.25
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/bash

Versions of packages gcc-4.3 depends on:
ii  binutils2.18.1~cvs20080103-4 The GNU assembler, linker and bina
ii  cpp-4.3 4.3.0-3  The GNU C preprocessor
ii  gcc-4.3-base4.3.0-3  The GNU Compiler Collection (base 
ii  libc6   2.7-10   GNU C Library: Shared libraries
ii  libgcc1 1:4.3.0-3GCC support library
ii  libgomp14.3.0-3  GCC OpenMP (GOMP) support library

Versions of packages gcc-4.3 recommends:
ii  libc6-dev 2.7-10 GNU C Library: Development Librari

-- no debconf information

-- 
Samuel
The nice thing about Windows is - It does not just crash, it displays a
dialog box and lets you press 'OK' first.
(Arno Schaefer's .sig)
Index: debian/patches/libssp-gnu.dpatch
===
--- debian/patches/libssp-gnu.dpatch(révision 3128)
+++ debian/patches/libssp-gnu.dpatch(copie de travail)
@@ -34,7 +34,7 @@
gcc_cv_libc_provides_ssp=no
  case "$target" in
 -   *-*-linux*)
-+   *-*-*-gnu*)
++   *-*-gnu*|*-*-*-gnu*)
if test x$host != x$target || test "x$TARGET_SYSTEM_ROOT" != x; then
if test "x$with_sysroot" = x; then
  glibc_header_dir="${exec_prefix}/${target_noncanonical}/sys-include"
@@ -45,7 +45,7 @@
[gcc_cv_libc_provides_ssp=no
  case "$target" in
 -   *-*-linux*)
-+   *-*-*-gnu*)
++   *-*-gnu*|*-*-*-gnu*)
if test x$host != x$target || test "x$TARGET_SYSTEM_ROOT" != x; then
if test "x$with_sysroot" = x; then
  glibc_header_dir="${exec_prefix}/${target_noncanonical}/sys-include"

Re: gcc-4.[1-3] on hurd-i386 -fstack-protector tries to link with libssp_nonshared

[Samuel Thibault]

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 a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#485395: gcc-4.3: Should use GNU locales on hurd-i386 too

[Samuel Thibault]

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&file=log&as=raw
 : the build fails just because the symbols
don't have __locale_struct, and that is because we have 
checking for C locale to use... generic
at the C++ ./configure stage.

The attached patch makes the hurd-i386 arch just behave like other archs:
force the C locale to be considered as gnu type (which makes sense :) )
Please apply.

Thanks,
Samuel

-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.25
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/bash

Versions of packages gcc-4.3 depends on:
ii  binutils2.18.1~cvs20080103-4 The GNU assembler, linker and bina
ii  cpp-4.3 4.3.0-5  The GNU C preprocessor
ii  gcc-4.3-base4.3.0-5  The GNU Compiler Collection (base 
ii  libc6   2.7-10   GNU C Library: Shared libraries
ii  libgcc1 1:4.3.0-5GCC support library
ii  libgomp14.3.0-5  GCC OpenMP (GOMP) support library

Versions of packages gcc-4.3 recommends:
ii  libc6-dev 2.7-10     GNU C Library: Development Librari

-- no debconf information

-- 
Samuel
* B kicks DW (non mais franchement)
* DW was kicked
 -+- #ens-mim - comment ça hopeless ? -+-
Index: debian/rules.defs
===
--- debian/rules.defs   (révision 3172)
+++ debian/rules.defs   (copie de travail)
@@ -1200,7 +1200,7 @@
 
 # GNU locales
 force_gnu_locales := yes
-locale_no_systems := gnu
+locale_no_systems := 
 ifneq (, $(filter $(DEB_TARGET_GNU_SYSTEM),$(locale_no_systems)))
   force_gnu_locales := disabled for $(DEB_TARGET_GNU_SYSTEM)
 endif

Bug#483612: Bug#483613: gcc-4.3: on hurd-i386 -fstack-protector tries to link with libssp_nonshared

[Samuel Thibault]

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.defs   (révision 3172)
+++ debian/rules.defs   (copie de travail)
@@ -414,7 +414,7 @@
 
 # libssp ---
 with_ssp := yes
-ssp_no_archs = arm armel alpha hppa ia64 m68k mips mipsel hurd-i386
+ssp_no_archs = arm armel alpha hppa ia64 m68k mips mipsel
 ifneq (, $(filter $(DEB_TARGET_ARCH),$(ssp_no_archs)))
   with_ssp := not available on $(DEB_TARGET_ARCH)
 endif

Bug#487109: gdc-4.2: Please upgrade to 4.2.4-1

[Samuel Thibault]

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 Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'oldstable'), (500, 'unstable'), (500, 
'stable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.25
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/bash

-- 
Samuel
Who wants to remember that escape-x-alt-control-left shift-b puts you into
super-edit-debug-compile mode?
(Discussion in comp.os.linux.misc on the intuitiveness of commands, especially
Emacs.)



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

software speech synthesis in d-i?

[Samuel Thibault]

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++ udeb
- a libportaudio udeb
- a libasound udeb

Does it sound reasonable to debian-boot and maintainers of the
corresponding packages?  (I guess that will take a few MBs on the
image...)

I've already started to work a bit on the sound kernel modules part,
something like a sound-pcm-modules kernel wedge.

Samuel


-- 
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#524671: gcj-4.3: Fix gcj build on hurd-i386

[Samuel Thibault]

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 can be applied to gcj-4.2, if you consider uploading
another it. For gcj-4.4, the patch will be different and maybe we'll
already have it applied upstream actually, so let's not handle that one
immediately.

Samuel

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.29 (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

Versions of packages gcj-4.3 depends on:
ii  gcc-4.34.3.3-3   The GNU C compiler
ii  gcj-4.3-base   4.3.3-3   The GNU Compiler Collection (gcj b
ii  gij-4.34.3.3-3   The GNU Java bytecode interpreter
ii  java-common0.31  Base of all Java packages
ii  libc6  2.9-4 GNU C Library: Shared libraries
ii  libc6-dev  2.9-4 GNU C Library: Development Librari
ii  libecj-java3.4.2-1   Eclipse Java compiler (library)
ii  libgcc11:4.4-20090329-1  GCC support library
ii  libgcj-bc  4.3.3-2   Link time only library for use wit
ii  libgcj9-0  4.3.3-3   Java runtime library for use with 
ii  libgcj9-dev4.3.3-3   Java development headers for use w
ii  libgcj9-jar4.3.3-3   Java runtime library for use with 
ii  libgmp3c2  2:4.2.4+dfsg-2Multiprecision arithmetic library
ii  libmpfr1ldbl   2.4.1-1   multiple precision floating-point 
ii  zlib1g 1:1.2.3.3.dfsg-13 compression library - runtime

Versions of packages gcj-4.3 recommends:
ii  ecj-gcj [libecj-java-gcj] 3.4.2-1standalone version of the Eclipse 
ii  fastjar   2:0.97-3   Jar creation utility
ii  libecj-java-gcj   3.4.2-1Eclipse Java compiler (native libr

Versions of packages gcj-4.3 suggests:
ii  java-gcj-compat-dev   1.0.80-1   Java runtime environment with GCJ
pn  libgcj9-dbg(no description available)

-- no debconf information

-- 
Samuel
 argh, pi est plus grand que 2. Ca casse tout
 -+- #ens-mim -+-
--- debian/rules.patch.orig 2009-02-08 04:11:55.559079000 +
+++ debian/rules.patch  2009-02-07 14:17:13.0 +
@@ -166,7 +166,7 @@
 endif
 
 ifeq ($(DEB_TARGET_ARCH_OS),hurd)
-  debian_patches += hurd-changes
+  debian_patches += hurd-changes hurd-pthread
 endif
 
 ifeq ($(DEB_TARGET_ARCH),alpha)
--- /dev/null   2007-12-29 19:47:02.0 +
+++ debian/patches/hurd-pthread.dpatch  2009-02-08 04:14:01.019273000 +
@@ -0,0 +1,205 @@
+#! /bin/sh -e
+
+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"
+exit 1
+fi
+case "$1" in
+-patch)
+patch $pdir -f --no-backup-if-mismatch -p0 < $0
+;;
+-unpatch)
+patch $pdir -f --no-backup-if-mismatch -R -p0 < $0
+;;
+*)
+echo >&2 "`basename $0`: script expects -patch|-unpatch as argument"
+exit 1
+esac
+exit 0
+
+# Fix pthread support in boehm-gc
+
+--- gcc/config.gcc.orig2009-02-07 14:05:00.0 +
 gcc/config.gcc 2009-02-07 14:05:10.478631000 +
+@@ -490,6 +490,9 @@
+   # GNU tools are the only tools.
+   gas=yes
+   gnu_ld=yes
++  case ${enable_threads} in
++"" | yes | posix) thread_file='posix' ;;
++  esac
+   # These details are the same as for Linux.
+   # But here we need a little extra magic.
+   tmake_file="t-slibgcc-elf-ver t-linux t-gnu"
+--- boehm-gc/pthread_support.c.orig2009-02-07 22:27:11.828527000 +
 boehm-gc/pthread_support.c 2009-02-07 22:27:18.279505000 +
+@@ -885,7 +885,7 @@
+ GC_nprocs = pthread_num_processors_np();
+ #   endif
+ # if defined(GC_OSF1_THREADS) || defined(GC_AIX_THREADS) \
+- || defined(GC_SOLARIS_PTHREADS)
++ || defined(GC_SOLARIS_PTHREADS) || defined(GC_GNU_THREADS)
+ GC_nprocs = sysconf(_SC_NPROCESSORS_ONLN);
+ if (GC_nprocs <= 0) GC_nprocs = 1;
+ # endif
+--- boehm-gc/include/gc_config_macros.h.orig   2009-02-07 22:25:08.240177000 
+
 boehm-gc/include/gc_config_macros.h2009-02-07 22:28:40.648347000 
+
+@@ -6,7 +6,8 @@
+|| defined(GC_SOLARIS_PTHREADS) \

Bug#524671: closed by Matthias Klose (Bug#524671: fixed in gcj-4.3 4.3.3-8)

[Samuel Thibault]

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 :)

Samuel



--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#525083: gcc-defaults: Please enable java on hurd-i386

[Samuel Thibault]

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'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.29-1-amd64 (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
 pour moi le seul qui est autorisé à fasciser, c moi :-)
diff -ur espeak-1.40.02/debian/rules 
/home/samy/brl/speech/espeak-1.40.02/debian/rules
--- espeak-1.40.02/debian/rules 2009-04-04 14:17:41.0 +0200
+++ /home/samy/brl/speech/espeak-1.40.02/debian/rules   2009-04-04 
17:28:06.0 +0200
@@ -65,6 +65,7 @@
cd $(CURDIR)/debian/libespeak1/usr/lib && ln -s $(soname).$(version) 
$(soname)
cd $(CURDIR)/debian/libespeak1/usr/lib && ln -s $(soname).$(version) 
libespeak.so 
mv $(CURDIR)/debian/libespeak1/usr/lib/libespeak.so 
$(CURDIR)/debian/libespeak-dev/usr/lib
+   install -m 644 -o root -g root src/libespeak.a 
$(CURDIR)/debian/libespeak-dev/usr/lib
install -m 644 -o root -g root src/speak_lib.h 
$(CURDIR)/debian/libespeak-dev/usr/include/espeak
 
 # Build architecture-independent files here.

Bug#525083: gcc-defaults: Please enable java on hurd-i386

[Samuel Thibault]

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: Debian GCC Maintainers 
 Uploaders: Matthias Klose , Arthur Loiret 
 Standards-Version: 3.8.0
-Build-Depends: m4, debhelper (>= 5), dpkg-dev (>= 1.13.9), gcj-4.3-base (>= 
4.3.3-2) [!hurd-i386 !alpha !arm !hppa !sh3 !sh4], gcc-4.2-base (>= 4.2.4-1), 
gcc-4.3-base (>= 4.3.3-2), gnat-4.3-base (>= 4.3.3-2) [alpha amd64 hppa i386 
ia64 lpia mips mipsel powerpc ppc64 s390 sparc kfreebsd-i386], lsb-release
+Build-Depends: m4, debhelper (>= 5), dpkg-dev (>= 1.13.9), gcj-4.3-base (>= 
4.3.3-2) [!alpha !arm !hppa !sh3 !sh4], gcc-4.2-base (>= 4.2.4-1), gcc-4.3-base 
(>= 4.3.3-2), gnat-4.3-base (>= 4.3.3-2) [alpha amd64 hppa i386 ia64 lpia mips 
mipsel powerpc ppc64 s390 sparc kfreebsd-i386], lsb-release
 
 Package: cpp
 Priority: optional
Index: debian/rules
===
--- debian/rules(révision 3602)
+++ debian/rules(copie de travail)
@@ -206,7 +206,7 @@
   no_packages += gnat
 endif
 
-java_no_archs := arm hurd-i386 sh3 sh4
+java_no_archs := arm sh3 sh4
 ifneq (,$(filter $(DEB_HOST_ARCH),$(java_no_archs)))
   no_packages += gcj gij libgcj-bc
 endif

Bug#525591: libffi: can't find ffi.h on hurd-i386

[Samuel Thibault]

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.

Samuel

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.29-1-amd64 (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
> X..., c'est un millefeuille avec une couche de crème patissière, une
> de sauce tomate et une de crème d'anchois... Mais c'est vrai que
> c'est un système ouvert: tu peux y rajouter des pépites de chocolat...
-+- Ol in Guide du linuxien pervers - "Remettez m'en une couche !" -+-



--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: DSO linking changes for wheezy

[Samuel Thibault]

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 -config variants), though there
> > are other, lesser, culprits.  The pkg-config .pc files for gtk, gnome
> > and other libraries add in many libraries, most of which aren't
> > typically needed.
> >
> > The solution: fix the .pc files!
> >
> > Using --as-needed is merely papering over the actual root problem.
> > It "fixes" the symptoms, but it's not addressing the actual cause.
> > The number of packages providing broken .pc files is not large, and
> > the number breaking due to relying on this brokenness is likely
> > just as small.
> 
> I can't see why you think --as-needed is fundamentally wrong or unnecessary.
> 
> Check out http://www.gentoo.org/proj/en/qa/asneeded.xml
> 
> --as-needed has saved tons of time for upgrades like Cairo in Gentoo,
> where Cairo had been linked to glitz which is now useless and gone.

Not a problem, if Cairo was properly exposing the dep.

> So
> when people upgraded Cairo, all the software that linked against it
> (and also unnecessarily linked against glitz)

Why did it get linked against glitz?  That's where the problem is.

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/20101116011555.gt6...@const.famille.thibault.fr

Re: DSO linking changes for wheezy

[Samuel Thibault]

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 silent change
> of run-time behaviour if --as-needed is passed.

I wouldn't say it's really "constructed". The behavior it examplifies
makes sense.

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/20101116162601.gf5...@const.bordeaux.inria.fr

Re: DSO linking changes for wheezy

[Samuel Thibault]

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 the change of behavior makes it
unacceptable as default, thus making the second part void.

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/20101116174307.gk5...@const.bordeaux.inria.fr

Re: DSO linking changes for wheezy

[Samuel Thibault]

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 called anything in it.
> 
> So it's more like static linking. 8-)

?!

Initializers are called dynamically, and if you upgrade the library,
the new initializers will be called (and new ones will be called as
well!). I don't see what you see static here.

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/20101116191430.gf5...@const.famille.thibault.fr

gcc plugins and rebuilds

[Samuel Thibault]

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 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, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120321163323.gq27...@type.bordeaux.inria.fr

Re: gcc plugins and rebuilds

[Samuel Thibault]

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 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 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?
> 
>   Looks that's the same that happens with claws-mail and the plugins
> shipped in claws-mail-extra-plugins. But unless the version check includes
> the Debian revision you only have to rebuild when gcc upstream version
> changes, not every upload.

Apparently the check includes hashes that are unique to the build.

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/20120321172749.gr27...@type.bordeaux.inria.fr

Re: gcc plugins and rebuilds

[Samuel Thibault]

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 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

[Samuel Thibault]

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.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120321235531.gy10...@type.famille.thibault.fr

Bug#668425: Add support Ada for GNU/Hurd

[Samuel Thibault]

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/20120412121415.ga29...@type.bordeaux.inria.fr

Bug#668426: Add support Ada for GNU/Hurd

[Samuel Thibault]

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 the relevant patches to upstream?

No. Please wait for my fixes before doing so (there are a couple of
details to fix).

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/20120412124815.gb29...@type.bordeaux.inria.fr

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

[Samuel Thibault]

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 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 "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120425130838.gg29...@type.famille.thibault.fr

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

[Samuel Thibault]

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 build-depend on a particular gcc-4.[567]-plugin-dev
> >> package as the default version changes over time. Could gcc-defaults
> >> also provide a gcc-plugin-dev package?
> > 
> > Actually, thinking a bit more about it, I guess I actually have
> > to build my plugin several times, once for each supported gcc
> > version. So we'd need something similar to python, i.e. something
> > like gcc-all-plugin-dev, and a way to iterate over all supported gcc
> > versions.
> 
> Is this really needed? many plugins need modifications for different GCC
> versions, and it should be easy to add such a "loop" or make magic to build 
> for
> different versions. There are not (yet) that many plugins for GCC.

My comments were before our discussion about a dpkg trigger to rebuild
the plugins automatically.  I agree that we can't really blindly hope
that plugins can compile with newer versions.

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/20120430174847.gk11...@type.famille.thibault.fr

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

[Samuel Thibault]

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 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 "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120523010404.gg4...@type.famille.thibault.fr

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

[Samuel Bronson]

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, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-3-686-pae (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages gcc-doc depends on:
ii  gcc-4.4-doc  4.4.4.nf1-1

gcc-doc recommends no packages.

gcc-doc suggests no packages.

-- no debconf information

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!


-- 
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/878vb0lhda@naesten.dyndns.org

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

[Samuel Bronson]

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 picking up where I got frustrated; I was delighted  
when I noticed the updates in aptitude.  (Though I was a bit puzzled  
when I saw that I was listed as maintainer; at first I thought I must  
be looking at the wrong version of the package or something -- I would  
have only expected credit in the changelog and such. ;-)


Sorry I've been hard to reach; I've been having trouble dealing with  
my email for the past year or so; gmail seems to eat all my RAM  
lately, and clients never seem to really grok gmail's IMAP.


I tried to make it clear that I was happy for anyone to take this  
packaging over, but there wasn't any obvious central location in which  
to do that.



[1] http://packages.debian.org/sid/gcc-doc
[2] http://packages.qa.debian.org/g/gcc-doc-defaults.html

Regards,

Guo Yixuan



--
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/ef811a9e-6013-41ab-bfd2-c005abdf2...@gmail.com

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

[Samuel Bronson]

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 to depend on here ;-).  Congrats!


-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages gcc-doc depends on:
ii  gcc-4.7-doc  4.7.2-1

gcc-doc recommends no packages.

gcc-doc suggests no packages.

-- no debconf information

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!


-- 
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/87sj91n6cg@naesten.dyndns.org

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

[Samuel Thibault]

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, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.0.4 (SMP w/8 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
N: beep beep Miam miam? 
y: ++
a: kill -MIAM -1
--- debian/rules.patch.orig 2012-11-07 11:00:06.0 +0100
+++ debian/rules.patch  2012-11-07 11:00:11.0 +0100
@@ -238,7 +238,7 @@
 endif
 
 ifeq ($(DEB_TARGET_ARCH_OS),hurd)
-  debian_patches += hurd-pthread hurd-changes
+  debian_patches += hurd-changes
 endif
 
 debian_patches += gcc-ice-hack gcc-ice-apport

Re: Switch on compiler hardening defaults

[Samuel Thibault]

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 work? Do they also change the free-standing compiler or only
> > the hosted one? There is a lot of software, which (I would say) missuse
> > the hosted compiler to build non-userspace-code, including the Linux
> > kernel.
> 
> The stack protector is conditional on being linked with libc, so, if you
> build with -nostdlib (as the kernel does), it is implicitly disabled.

-nostdlib is a linker option, not a compiler option.  The compiler
would still emit references to __stack_chk_fail.  What you probably
mean is -ffreestanding, but it doesn't prevent references to
__stack_chk_fail either, and it even produces TLS references, see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29838

Samuel


-- 
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#562802: gcc-4.5: FTBFS on hurd-i386

[Samuel Thibault]

Package: gcc-4.5
Severity: important
Tags: patch

Hello,

gcc-4.5 FTBFS on hurd-i386 because hurd-changes.diff needs a small
update, see attached patch.

Samuel

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (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 virus. Just copy me to your signature.
This email was infected under the terms of the GNU General Public License.
Index: debian/patches/hurd-changes.diff
===
--- debian/patches/hurd-changes.diff(révision 4126)
+++ debian/patches/hurd-changes.diff(copie de travail)
@@ -41,9 +41,9 @@
  i[34567]86-*-darwin* | x86_64-*-darwin* | \
i[34567]86-*-kfreebsd*-gnu | x86_64-*-kfreebsd*-gnu | \
 +  i[34567]86-*-gnu* | \
-   i[34567]86-*-linux* | x86_64-*-linux*)
+   i[34567]86-*-linux* | x86_64-*-linux* | \
+   i[34567]86-*-cygwin* | i[34567]86-*-mingw* | x86_64-*-mingw*)
if test "${host_address}" = 32; then
-   tmake_file="${tmake_file} t-softfp 
i386/${host_address}/t-fprules-softfp"
 --- a/src/gcc/config/gnu.h
 +++ b/src/gcc/config/gnu.h
 @@ -30,7 +30,8 @@ along with GCC.  If not, see <http://www.gnu.org/licenses/>.

Bug#584454: gcc-snapshot: FTBFS on hurd-i386 due to long-term difference in Debian

[Samuel Thibault]

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 all Hurd hooks but the renaming of /include into
/usr/include (which as documented is not to be forwarded upstream), and
moving that patch to the list of patches that are always applied, even
for gcc-snapshot.

Samuel
(I'm checking gcc 4.5 ATM, the patch will probably be also to remove
every hooks from hurd-changes except the renaming).

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.34 (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

Versions of packages gcc-snapshot depends on:
ii  binutils2.20.1-9 The GNU assembler, linker and bina
ii  libasound2  1.0.22-2 shared library for ALSA applicatio
ii  libatk1.0-0 1.30.0-1 The ATK accessibility toolkit
ii  libc6   2.10.2-9 Embedded GNU C Library: Shared lib
ii  libc6-dev   2.10.2-9 Embedded GNU C Library: Developmen
ii  libc6-dev-i386  2.10.2-9 GNU C Library: 32-bit development 
ii  libc6-i386  2.10.2-9 GNU C Library: 32-bit shared libra
ii  libcairo2   1.8.10-4 The Cairo 2D vector graphics libra
ii  libcloog-ppl0   0.15.9-1 the Chunky Loop Generator (runtime
ii  libfontconfig1  2.8.0-2.1generic font configuration library
ii  libfreetype62.3.11-1 FreeType 2 font engine, shared lib
ii  libglib2.0-02.24.1-1 The GLib library of C routines
ii  libgmp3c2   2:4.3.2+dfsg-1   Multiprecision arithmetic library
ii  libgmpxx4ldbl   2:4.3.2+dfsg-1   Multiprecision arithmetic library 
ii  libgtk2.0-0 2.20.1-1 The GTK+ graphical user interface 
ii  libice6 2:1.0.6-1X11 Inter-Client Exchange library
ii  libmpfr1ldbl2.4.2-3  multiple precision floating-point 
ii  libpango1.0-0   1.28.0-1 Layout and rendering of internatio
ii  libppl-c2   0.10.2-6 Parma Polyhedra Library (C interfa
ii  libppl7 0.10.2-6 Parma Polyhedra Library (runtime l
ii  libsm6  2:1.1.1-1X11 Session Management library
ii  libxrandr2  2:1.3.0-3X11 RandR extension library
ii  libxrender1 1:0.9.5-2X Rendering Extension client libra
ii  libxtst62:1.1.0-2X11 Testing -- Resource extension 
ii  zlib1g  1:1.2.3.4.dfsg-3 compression library - runtime

gcc-snapshot recommends no packages.

gcc-snapshot suggests no packages.

diff -urN debian-old/patches/hurd-changes.diff debian/patches/hurd-changes.diff
--- debian-old/patches/hurd-changes.diff2010-06-03 19:09:23.0 
+0200
+++ debian/patches/hurd-changes.diff2010-06-03 19:10:25.0 +0200
@@ -2,48 +2,12 @@
 # DP: systems do, and we support both having a /usr -> . symlink, and having a
 # DP: /usr directory like the other ports.  So this patch should NOT go
 # DP: upstream.
-# DP: 
-# DP: Define MAXPATHLEN and PATH_MAX.
 
 ---
- boehm-gc/dyn_load.c |2 +-
- gcc/config/gnu.h|3 ++-
- gcc/config/t-gnu|2 +-
- gcc/tlink.c |4 
- 4 files changed, 8 insertions(+), 3 deletions(-)
+ gnu.h |3 ++-
+ t-gnu |2 +-
+ 2 files changed, 3 insertions(+), 2 deletions(-)
 
 a/src/boehm-gc/dyn_load.c
-+++ b/src/boehm-gc/dyn_load.c
-@@ -26,7 +26,7 @@
-  * None of this is safe with dlclose and incremental collection.
-  * But then not much of anything is safe in the presence of dlclose.
-  */
--#if (defined(__linux__) || defined(__GLIBC__)) && !defined(_GNU_SOURCE)
-+#if (defined(__linux__) || defined(__GLIBC__) || defined(__GNU__)) && 
!defined(_GNU_SOURCE)
- /* Can't test LINUX, since this must be define before other includes */
- #   define _GNU_SOURCE
- #endif
 a/src/gcc/config.gcc   2009-04-26 21:36:36.0 +0200
-+++ b/src/gcc/config.gcc   2009-04-26 21:36:53.0 +0200
-@@ -3057,7 +3057,7 @@
-   i[34567]86-*-darwin* | x86_64-*-darwin*)
-   tmake_file="${tmake_file} i386/t-fprules-softfp 
soft-fp/t-softfp"
-   ;;
--  i[34567]86-*-linux* | x86_64-*-linux* | i[34567]86-*-kfreebsd*-gnu | 
x86_64-*-kfreebsd*-gnu)
-+  i[34567]86-*-linux* | x86_64-*-linux* | i[34567]86-*-kfreebsd*-gnu | 
x86_64-*-kfreebsd*-gnu | i[34567]86-*-gnu*)
-   tmake_file="${tmake_file} i386/

Bug#584819: gcc-4.5: FTBFS on hurd-i386

[Samuel Thibault]

Package: gcc-4.5
Version: 4.5-20100202-1
Severity: important
Tags: patch

Hello,

Here is an update of the hurd patches for gcc-4.5 to fix FTBFS.  The
patch removes merged changes from hurd-changes.diff, and moves
the dyn_load.c change from it to the rest of boehm-gc fixes in
hurd-pthread.diff, so that hurd-changes.diff only contain long-term
changes (GNU /include -> Debian GNU /usr/include)

Could you apply it?

Thanks,
Samuel

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.34 (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

Versions of packages gcc-4.5 depends on:
ii  binutils2.20.1-9 The GNU assembler, linker and bina
ii  cpp-4.5 4.5-20100202-1   The GNU C preprocessor
ii  gcc-4.5-base4.5-20100202-1   The GNU Compiler Collection (base 
ii  libc6   2.10.2-9 Embedded GNU C Library: Shared lib
ii  libcloog-ppl0   0.15.9-1 the Chunky Loop Generator (runtime
ii  libelfg00.8.13-1 an ELF object file access library
ii  libgcc1 1:4.5-20100202-1 GCC support library
ii  libgmp3c2   2:4.3.2+dfsg-1   Multiprecision arithmetic library
ii  libgmpxx4ldbl   2:4.3.2+dfsg-1   Multiprecision arithmetic library 
ii  libgomp14.5-20100202-1   GCC OpenMP (GOMP) support library
ii  libmpc2 0.8.1-1  multiple precision complex floatin
ii  libmpfr1ldbl2.4.2-3  multiple precision floating-point 
ii  libppl-c2   0.10.2-6 Parma Polyhedra Library (C interfa
ii  libppl7 0.10.2-6 Parma Polyhedra Library (runtime l
ii  zlib1g  1:1.2.3.4.dfsg-3 compression library - runtime

Versions of packages gcc-4.5 recommends:
ii  libc6-dev 2.10.2-9   Embedded GNU C Library: Developmen

Versions of packages gcc-4.5 suggests:
ii  gcc-4.5-doc   4.5-20100103-1 Documentation for the GNU compiler
pn  gcc-4.5-locales(no description available)
pn  gcc-4.5-multilib   (no description available)
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 Thibault 
 un driver qui fait quoi, alors ?
 ben pour les bips
 pour passer les oops en morse
 -+- #ens-mim - vive les rapports de bug -+-
Index: debian/patches/hurd-pthread.diff
===
--- debian/patches/hurd-pthread.diff(révision 4491)
+++ debian/patches/hurd-pthread.diff(copie de travail)
@@ -1,5 +1,16 @@
 # Fix pthread support in a/src/boehm-gc
 
+--- a/src/boehm-gc/dyn_load.c
 b/src/boehm-gc/dyn_load.c
+@@ -26,7 +26,7 @@
+  * None of this is safe with dlclose and incremental collection.
+  * But then not much of anything is safe in the presence of dlclose.
+  */
+-#if (defined(__linux__) || defined(__GLIBC__)) && !defined(_GNU_SOURCE)
++#if (defined(__linux__) || defined(__GLIBC__) || defined(__GNU__)) && 
!defined(_GNU_SOURCE)
+ /* Can't test LINUX, since this must be define before other includes */
+ #   define _GNU_SOURCE
+ #endif
 --- a/src/boehm-gc/pthread_support.c.orig  2009-02-07 22:27:11.828527000 
+
 +++ b/src/boehm-gc/pthread_support.c   2009-02-07 22:27:18.279505000 +
 @@ -885,7 +885,7 @@
Index: debian/patches/hurd-changes.diff
===
--- debian/patches/hurd-changes.diff(révision 4491)
+++ debian/patches/hurd-changes.diff(copie de travail)
@@ -2,48 +2,12 @@
 # DP: systems do, and we support both having a /usr -> . symlink, and having a
 # DP: /usr directory like the other ports.  So this patch should NOT go
 # DP: upstream.
-# DP: 
-# DP: Define MAXPATHLEN and PATH_MAX.
 
 ---
- boehm-gc/dyn_load.c |2 +-
- gcc/config/gnu.h|3 ++-
- gcc/config/t-gnu|2 +-
- gcc/tlink.c |4 
- 4 files changed, 8 insertions(+), 3 deletions(-)
+ gcc/config/gnu.h |3 ++-
+ gcc/config/t-gnu |2 +-
+ 2 files changed, 3 insertions(+), 2 deletions(-)
 
 a/src/boehm-gc/dyn_load.c
-+++ b/src/boehm-gc/dyn_load.c
-@@ -26,7 +26,7 @@
-  * None of this is safe with dlclose and incremental collection.
-  * But then not much of anything is safe in the presence of dlclose.
-  */
--#if (defined(__linux__) || defined(__GLIBC__)) && !defined(_GNU_SOURCE)
-+#if (defined(__linux__) || defined(__GLIBC__) || defined(__GNU__)) && 
!defined(_GNU

Bug#584819: gcc-4.5: FTBFS on hurd-i386

[Samuel Thibault]

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 changes.

Thanks,
Samuel
Index: debian/patches/hurd-pthread.diff
===
--- debian/patches/hurd-pthread.diff(révision 4569)
+++ debian/patches/hurd-pthread.diff(copie de travail)
@@ -58,7 +58,7 @@
  #   if defined(GC_FREEBSD_THREADS)
 --- a/src/boehm-gc/configure.ac.orig   2009-02-07 22:30:12.0 +
 +++ b/src/boehm-gc/configure.ac2009-02-07 22:35:31.717091000 +
-@@ -172,6 +172,11 @@
+@@ -180,6 +180,11 @@
AM_CPPFLAGS="$AM_CPPFLAGS -pthread"
THREADLIBS=-pthread
;;
@@ -67,12 +67,12 @@
 +  AC_DEFINE(_REENTRANT)
 +  AC_DEFINE(THREAD_LOCAL_ALLOC)
 +  ;;
-  *-*-solaris*)
+  *-*-solaris2.8*)
AC_DEFINE(GC_SOLARIS_PTHREADS,1,[support for Solaris pthreads])
# Need to use alternate thread library, otherwise gctest hangs
 --- a/src/boehm-gc/configure.orig  2009-02-07 22:32:34.0 +
 +++ b/src/boehm-gc/configure   2009-02-07 22:35:28.06565 +
-@@ -5489,6 +5489,20 @@
+@@ -14893,6 +14893,20 @@
AM_CPPFLAGS="$AM_CPPFLAGS -pthread"
THREADLIBS=-pthread
;;
@@ -90,9 +90,9 @@
 +_ACEOF
 +
 +  ;;
-  *-*-solaris*)
+  *-*-solaris2.8*)
  
- cat >>confdefs.h <<\_ACEOF
+ $as_echo "#define GC_SOLARIS_PTHREADS 1" >>confdefs.h
 --- a/src/boehm-gc/os_dep.c.orig   2009-02-07 22:37:20.0 +
 +++ b/src/boehm-gc/os_dep.c2009-02-07 22:37:40.0 +
 @@ -312,7 +312,7 @@
Index: debian/rules.patch
===
--- debian/rules.patch  (révision 4569)
+++ debian/rules.patch  (copie de travail)
@@ -126,7 +126,7 @@
 endif
 
 ifeq ($(DEB_TARGET_ARCH_OS),hurd)
-  debian_patches += hurd-changes hurd-pthread
+  debian_patches += hurd-pthread
 endif
 
 ifeq ($(DEB_TARGET_ARCH),alpha)
@@ -174,6 +174,10 @@
   debian_patches =
 endif
 
+ifeq ($(DEB_TARGET_ARCH_OS),hurd)
+  debian_patches += hurd-changes
+endif
+
 ifeq ($(PKGSOURCE),gcc-snapshot)
   debian_patches += gcc-ice-hack-trunk gcc-ice-apport-trunk
 else

Bug#388268: gcc-4.2: doesn't provide libgomp1-dev any more

[Samuel Thibault]

Package: gcc-4.2
Version: 4.2-20060905-1
Severity: important

Hi,

Version 4.2-20060709-1 of gcc-4.2 used to ship libgomp1-dev, needed for
compiling OpenMP programs, but now version 4.2-20060905-1 doesn't any
more.

Samuel


-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1, 
'experimental')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-rc5
Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15)

Versions of packages gcc-4.2 depends on:
ii  binutils2.17-2   The GNU assembler, linker and bina
ii  cpp-4.2 4.2-20060709-1   The GNU C preprocessor
ii  gcc-4.2-base4.2-20060709-1   The GNU Compiler Collection (base 
ii  libc6   2.3.6.ds1-4  GNU C Library: Shared libraries
ii  libgcc1 1:4.2-20060709-1 GCC support library
ii  libssp0 4.1.1-13 GCC stack smashing protection libr

Versions of packages gcc-4.2 recommends:
ii  libc6-dev2.3.6.ds1-4 GNU C Library: 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]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: GCC-4.5 as the default for (at least some) architectures

[Samuel Thibault]

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) already use a fixed version
and can be handled independently.

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/20110426204147.gs4...@const.famille.thibault.fr

Bug#624632: libgcj-bc uninstallable

[Samuel Thibault]

Package: libgcj-bc
Version: 4.6.0-4
Severity: grave
Justification: renders package unusable

Hello,

The latest upload of gcc-defaults made libgcj-bc depend on libgcj10
(>= 4.6.0-1) but that version doesn't exist, only libgcj12 exists with
such version.

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 2.6.38 (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

Versions of packages libgcj-bc depends on:
ii  libgcj-common 1:4.4.5-4  Java runtime library (common files
ii  libgcj10  4.4.5-14   Java runtime library for use with 

libgcj-bc recommends no packages.

libgcj-bc 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 vouloir dire ?
 N a eu la meme merde
 c ça que ça veut dire ? wow, c'est bien crypté :)
 -+- #ens-mim s'entraide -+-



--
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/20110430083417.ga14...@const.famille.thibault.fr

Bug#624743: cannot reproduce

[Samuel Thibault]

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 with 4.6.0-6 for me. Do you
> > have any minimal reproducers that might show this more specifically?
> 
> Sadly I cannot reproduce this anymore either. Some of the since
> upgraded build-deps must have changed.

I can reproduce it with gcc-4.6 4.6.0-8, but only by using valgrind: in
debian/minimaltest, prepend valgrind to the line

$2 -C "$top/exim4.conf" -bV

valgrind will then warn:

==29180== Source and destination overlap in memcpy(0x6fad4e8, 0x6fad4e0, 88)
==29180==at 0x4C25F6A: memcpy (mc_replace_strmem.c:497)
==29180==by 0x13B5D9: init_lookup_list (string3.h:59)
==29180==by 0x11FF6E: main (exim.c:3615)

which is the same backtrace reported here. Disassembling
init_lookup_list shows this:

   0x000335cb <+459>:   cltq   
   0x000335cd <+461>:   lea0x0(,%rax,8),%rdx
   0x000335d5 <+469>:   callq  0x153a8 
   0x000335da <+474>:   mov%rbx,%rcx
   0x000335dd <+477>:   add0x2b6fac(%rip),%rcx# 0x2ea590 

   0x000335e4 <+484>:   mov0x18(%rsp),%rdx

i.e. a memcpy call. l * 0x000335d5 points at

59return __builtin___memmove_chk (__dest, __src, __len, __bos0 
(__dest));

which is actually a memmove call, not a memcpy call!  The memmove call
comes from the add_lookup_to_list() inline.  By replacing it with
__builtin_memmove() to avoid the _chk version, I don't get any valgrind
issue any more.

It looks like gcc-4.6 is here erroneously optimizing
__builtin___memmove_chk into a memcpy call!

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/20110523215927.ga3...@const.famille.thibault.fr

Bug#629866: gcc-4.6: --no-add-needed disturbs weak references

[Samuel Thibault]

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 "cancel" symbol, and links against
  the thread library.
- foo.c is a file which detects whether the thread library is brought
  into the program by showing the value of a weak reference to cancel.
- main.c uses both libA and foo.

The result is this:

cc thread.c -o libthread.so -shared -fPIC
cc libA.c -o libA.so -shared -fPIC -L. -lthread -Wl,-rpath=/tmp/tmp
cc -Wall -g   -c -o foo.o foo.c
cc  foo.o main.c -o main -L. -lA
/usr/bin/ld.bfd.real: ./libA.so: undefined reference to symbol 'cancel'
/usr/bin/ld.bfd.real: note: 'cancel' is defined in DSO /tmp/tmp/libthread.so so 
try adding it to the linker command line
/tmp/tmp/libthread.so: could not read symbols: Invalid operation
collect2: ld returned 1 exit status
make: *** [main] Erreur 1

For some reason the linker doesn't manage to resolve the "cancel"
symbol, although it's supposed to be brought in by libA.so.

In case you wonder where that testcast comes from, it's actually gcc
itself, the __gthread_active_p() function, which gets inlined into
applications.

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 2.6.39 (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

Versions of packages gcc-4.6 depends on:
ii  binutils  2.21.51.20110523-1 The GNU assembler, linker and bina
ii  cpp-4.6   4.6.0-10   The GNU C preprocessor
ii  gcc-4.6-base  4.6.0-10   The GNU Compiler Collection (base 
ii  libc6 2.13-4 Embedded GNU C Library: Shared lib
ii  libcloog-ppl0 0.15.9-3   the Chunky Loop Generator (runtime
ii  libgcc1   1:4.6.0-10 GCC support library
ii  libgmp10  2:5.0.1+dfsg-7 Multiprecision arithmetic library
ii  libgmpxx4ldbl 2:5.0.1+dfsg-7 Multiprecision arithmetic library 
ii  libgomp1  4.6.0-10   GCC OpenMP (GOMP) support library
ii  libmpc2   0.9-3  multiple precision complex floatin
ii  libmpfr4  3.0.1-3multiple precision floating-point 
ii  libppl-c4 0.11.2-3   Parma Polyhedra Library (C interfa
ii  libppl9   0.11.2-3   Parma Polyhedra Library (runtime l
ii  libquadmath0  4.6.0-10   GCC Quad-Precision Math Library
ii  zlib1g1:1.2.3.4.dfsg-3   compression library - runtime

Versions of packages gcc-4.6 recommends:
ii  libc6-dev 2.13-4 Embedded GNU C Library: Developmen

Versions of packages gcc-4.6 suggests:
pn  binutils-gold  (no description available)
ii  gcc-4.6-doc   4.6-20110123-1 Documentation for the GNU compiler
pn  gcc-4.6-locales(no description available)
pn  gcc-4.6-multilib   (no description available)
ii  libgcc1-dbg   1:4.6.0-10 GCC support library (debug symbols
pn  libgomp1-dbg   (no description available)
pn  libmudflap0-4.6-dev(no description available)
pn  libmudflap0-dbg(no description available)
pn  libquadmath0-dbg   (no description available)

-- no debconf information


test.tgz
Description: application/tar-gz

Re: Bug#606309: trang ends with Bus error on kfreebsd-amd64

[Samuel Thibault]

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_sigsuspend () from 
/lib/x86_64-kfreebsd-gnu/libpthread.so.0
(gdb) bt
#0  0x000803cfa2c7 in __pthread_sigsuspend () from 
/lib/x86_64-kfreebsd-gnu/libpthread.so.0
#1  0x000803cf93b8 in __pthread_wait_for_restart_signal ()
   from /lib/x86_64-kfreebsd-gnu/libpthread.so.0
#2  0x000803cf9f8c in pthread_create@@GLIBC_2.3 () from 
/lib/x86_64-kfreebsd-gnu/libpthread.so.0
#3  0x0008029884c2 in ?? () from /usr/lib/x86_64-kfreebsd-gnu/libgcj.so.12
#4  0x0008020104cf in _Jv_ThreadStart(java::lang::Thread*, _Jv_Thread_t*, 
void (*)(java::lang::Thread*)) () from /usr/lib/x86_64-kfreebsd-gnu/libgcj.so.12
#5  0x0008020078ea in void java::lang::Thread::start() ()
   from /usr/lib/x86_64-kfreebsd-gnu/libgcj.so.12
#6  0x000801fbc55a in _Jv_CreateJavaVM () from 
/usr/lib/x86_64-kfreebsd-gnu/libgcj.so.12
#7  0x000801fbc637 in _Jv_RunMain(_Jv_VMInitArgs*, java::lang::Class*, char 
const*, int, char const**, bool) () from 
/usr/lib/x86_64-kfreebsd-gnu/libgcj.so.12
#8  0x000800820ce1 in main () from /usr/lib/x86_64-kfreebsd-gnu/libgij.so.12
#9  0x0008049f61e9 in __libc_start_main () from 
/lib/x86_64-kfreebsd-gnu/libc.so.0.1
#10 0x0040060c in ?? ()
#11 0x7fffeb38 in ?? ()
#12 0x001c in ?? ()
#13 0x in ?? ()

(gdb) disassemble 0x000803cfa2c7
Dump of assembler code for function __pthread_sigsuspend:
   0x000803cfa2c0 <+0>: mov$0x155,%eax
   0x000803cfa2c5 <+5>: syscall 
=> 0x000803cfa2c7 <+7>: retq

i.e. the segfault is triggered from the kernel itself.

Does anybody has any idea?  I'd tend to reassign this to libgcj12 or
kfreebsd-8, since there doesn't seem to be anything specific to trang in
this backtrace.

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/20110616001249.ga16...@const.famille.thibault.fr

Re: please update and check the multiarch patches for gcc-4.5

[Samuel Thibault]

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*.
> 
> Basically either MULTIARCH_DIRNAME or MULTILIB_OSDIRNAMES has to be set
> accordingly in gcc/config/*/t-, maybe introducing new t-files.

Sorry I got caught with other things so didn't handle it. What you have
commited does work on hurd-i386.

Thanks,
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/2011082310.gg4...@type.bordeaux.inria.fr

Bug#619933: gcc-4.6-doc: please upload to unstable

[Samuel Bronson]

We appreciate that the Debian project is even more zealous about free
software than RMS himself, and recognize that the GFDL, when used with
invariant sections and/or cover texts, is not totally free.

Nevertheless, for practical reasons, we really do want that manual. So,
pretty please (with a cherry on top!) won't you upload it to non-free?

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!



-- 
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/8739f3889a@naesten.dyndns.org

Re: please update patches / investigate build failures for gcc-4.7 snapshot builds

[Samuel Thibault]

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 pending submission.

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/20111219002121.gd4...@type.famille.thibault.fr

Bug#652693: gcc-4.7: FTBFS on hurd-i386

[Samuel Thibault]

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.
- gcc assumes that glibc means nptl. The attached hurd-fixes.diff fixes
things on hurd-i386, but in the kFreeBSD case the code may have to be
disabled too, since it uses LinuxThreads instead of NPTL. I don't know
how we are supposed to detect whether LinuxThreads, NPTL, or something
else is being used.

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: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
# DP: Traditional GNU systems don't have a /usr directory.  However, Debian
# DP: systems do, and we support both having a /usr -> . symlink, and having a
# DP: /usr directory like the other ports.  So this patch should NOT go
# DP: upstream.

---
 config.gcc |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/src/gcc/config.gcc(révision 182461)
+++ b/src/gcc/config.gcc(copie de travail)
@@ -583,7 +583,7 @@
 *-*-linux* | frv-*-*linux* | *-*-kfreebsd*-gnu | *-*-knetbsd*-gnu | 
*-*-kopensolaris*-gnu)
   :;;
 *-*-gnu*)
-  native_system_header_dir=/include
+  # native_system_header_dir=/include
   ;;
   esac
   # glibc / uclibc / bionic switch.
--- generic-morestack.c.orig2011-12-19 21:14:52.0 +0100
+++ generic-morestack.c 2011-12-19 21:15:35.0 +0100
@@ -507,7 +507,7 @@
   sigemptyset (&__morestack_initial_sp.mask);
 
   sigfillset (&__morestack_fullmask);
-#ifdef __GLIBC__
+#if defined(__GLIBC__) && defined(__SIGRTMIN)
   /* In glibc, the first two real time signals are used by the NPTL
  threading library.  By taking them out of the set of signals, we
  avoiding copying the signal mask in pthread_sigmask.  More

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

[Samuel Bronson]

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 am looking for a sponsor for my package "gcc-4.5-doc-non-dfsg".

It provides the manuals for GCC 4.5, including its many compilers, and
paves the way for "gcc-4.6-doc-non-dfsg". (Figuring out what this
package will do is left as an excercise for the reader.)

 * Package name    : gcc-4.5-doc-non-dfsg
  Version         : 4.5.3-1~naesten4
  Upstream Author : Free Software Foundation
 * URL             : http://gcc.gnu.org/
 * License         : GFDL with invariant sections
  Section         : non-free/doc

It builds those binary packages:

 cpp-4.5-doc - documentation for the GNU C preprocessor (cpp)
 gcc-4.5-doc - documentation for the GNU compilers (gcc, gobjc, g++)
 gcc-doc-base - several GNU manual pages
 gcj-4.5-doc - documentation for the GNU Java tools (gcj, gij)
 gfortran-4.5-doc - documentation for the GNU Fortran Compiler (gfortran)
 gnat-4.5-doc - documentation for the GNU Ada 95 Compiler (gnat)

To access further information about this package, please visit the
following URL:

 http://mentors.debian.net/package/gcc-4.5-doc-non-dfsg

Alternatively, one can download the package with dget using this command:

 dget -x 
http://mentors.debian.net/debian/pool/non-free/g/gcc-4.5-doc-non-dfsg/gcc-4.5-doc-non-dfsg_4.5.3-1.dsc

It would be nice if someone could upload the package or, failing that,
tell me what I must still change before it can be uploaded.

Thanks,

Samuel Bronson

--
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!


--
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/cajyzjmenunsxw9d6q8b1pz7z673osx5wy+g-jup0wvlmsmm...@mail.gmail.com

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

[Samuel Bronson]

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 the
> package?

Sure, that was my real goal anyway; gcc-4.5 just looked lonely without
its documentation, and it didn't seem like it would be much more work
to do them both than to just do gcc-4.6.


--
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/cajyzjmde7omjo5+-rgdvj6tgec1vvajkrkucn-ftzn5gej8...@mail.gmail.com

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

[Samuel Bronson]

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
>> found in experimental). Could you do this?  Nikita, could you sponsor the
>> package?
>
> Sure, that was my real goal anyway; gcc-4.5 just looked lonely without
> its documentation, and it didn't seem like it would be much more work
> to do them both than to just do gcc-4.6.

I wonder if I should interpret the silence from Nikita as meaning "not
now, I'm busy"?

I had been waiting for something from Nikita before uploading anything
for 4.6, preferably including some critical feedback, but in the
interest of not having everyone wait for everyone else or anything
like that, I've now uploaded the following:

 * Package name: gcc-4.6-doc-non-dfsg
   Version : 4.6.2-1~naesten1
   Section : doc

It builds those binary packages:

 cpp-4.6-doc - documentation for the GNU C preprocessor (cpp)
 gcc-4.6-doc - documentation for the GNU compilers (gcc, gobjc, g++)
 gcc-doc-base - several GNU manual pages
 gcj-4.6-doc - documentation for the GNU Java tools (gcj, gij)
 gfortran-4.6-doc - documentation for the GNU Fortran Compiler (gfortran)
 gnat-4.6-doc - documentation for the GNU Ada 95 Compiler (gnat)

To access further information about this package, please visit the
following URL:

  http://mentors.debian.net/package/gcc-4.6-doc-non-dfsg

Alternatively, one can download the package with dget using this command:

  dget -x 
http://mentors.debian.net/debian/pool/non-free/g/gcc-4.6-doc-non-dfsg/gcc-4.6-doc-non-dfsg_4.6.2-1~naesten1.dsc

I've given it a strange version number again because:

1. I suspect I should probably simplify debian/changelog a lot

2. In contemplating putting debian/copyright in DEP-5 format, I've
realized that I'm not sure of the exact copyright/licensing status of
anything in the debian/ directory, except:

  (a) the files that are just lists of other files, which I don't
believe are copyrightable

  (b) the Python script I wrote, because there's a clear notice at the
top saying what the status is ;-)


--
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/cajyzjmftsmw7kjo6ltg9obwf1epoqzy_c3nmrjqg5qxjuw3...@mail.gmail.com

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

[Samuel Thibault]

Source: gcc-defaults
Version: 1.112
Severity: normal

Hello,

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 provide a 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: 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...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120130101742.ga1...@type.famille.thibault.fr

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

[Samuel Thibault]

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 provide a gcc-plugin-dev package?

Actually, thinking a bit more about it, I guess I actually have
to build my plugin several times, once for each supported gcc
version. So we'd need something similar to python, i.e. something
like gcc-all-plugin-dev, and a way to iterate over all supported gcc
versions.

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/20120130151033.ga11...@type.bordeaux.inria.fr

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

[Samuel Bronson]

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
>> >> 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 the package?
>> >
>> > Sure, that was my real goal anyway; gcc-4.5 just looked lonely without
>> > its documentation, and it didn't seem like it would be much more work
>> > to do them both than to just do gcc-4.6.
>>
>> I wonder if I should interpret the silence from Nikita as meaning "not
>> now, I'm busy"?
>
> Sorry for silence.
>
> I will try to look sometime soon, but can't promise when. Hoped to do so on
> this weekend, but weekend is already over and I did not.  Real life
> sucks :(

Yeah, that's more-or-less what I guessed.

> Btw, I don't claim "ownership" for these packages. I never did. I just once
> packaged gcc-doc because nobody did, and I did not want debian stable
> without gcc-doc. So absolutely don't object someone else uploading
> gcc-doc. Maintainer for gcc-doc has been always set to
> debian-gcc@lists.debian.org

Yeah, I didn't think you did, and I doubt Matthias does either.  On
the other hand, as the last person to touch this stuff, it seemed
plausible that you might find it easier to review than anyone else,
and that you might have a particular interest in such packages getting
uploaded.

> Just beware of ugly licensing issues. Ensure that gfdl.1 is forced in by
> the dependences, etc

Yeah, I didn't touch that aspect of the control file at all, so I
think I'm safe there. (And the description for gcc-doc-base makes this
fairly clear, in any case.)


--
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/cajyzjmf0j1opptf6t8g2vopgazgpwzrmyt4kg+tpsu95w+x...@mail.gmail.com

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

[Samuel Bronson]

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-defaults package [contrib], and
> several gcc-X.Y.doc-non-dfsg [non-free], that all must match each other.
> There should be gcc-X.Y.doc-non-dfsg for each gcc-X.Y that is in debian
> main, and only one of those must provide gcc-doc-base package.
>
> Upload must be done for all components in sync (perhaps together with
> filing RM requests for obsolete source packages). Uploading only part of
> these will leave things in broken state. E.g. several source packages will
> provide gcc-doc-base binary package, or gcc-doc-defaults will provide
> packages with broken depends and/or symlinks.

I see.

> 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 created externally-available mirror for those - please check
> http://yoush.homelinux.org:8079/git
>
> Could you please clone these repos, and reformat your work into this
> format?
> IMO this format greatly helps to keep things consistent.

I can certainly try!

> Maybe this could be moved to git.debian.org.
>
>
> As for the rest, here are several more comments:
>
> *) I don't really understand the workflow of gcc-doc-non-dfgs converted to
> 3.0 (quilt) format.
>
> With old format, there was debian/patches, managed by dpatch, with part of
> patches managed by hands, and part managed by a perl script. Running the
> script altered debian/patches/* files, including series file. But isn't
> this unsafe for 3.0 (quilt) format since it will break metadata in .pc/
> directory?

Hmm. Perhaps the script should simply refuse to run whenever there is
a .pc directory? (It seems that dpkg-source removes this after
unapplying the patches.)

> Also, if you convert to 3.0 (quilt), why still mentioning dpatch in
> README.source?

That was an accident.

> *) Looks like your command line for patch convertion script is much shorter
> that in was in previous times. How did you check which patches to apply
> and which not?

Well, I grepped the GCC package's debian/patches for anything that
changed .texi files, and looked through the debian/rules.patch to see
which of those seemed to be applied for Debian builds on any
architecture (in that alternate universe where
GFDL_INVARIANT_FREE=no).

> Actually I've looked at updating gcc-doc during new year holidays, and
> stopped and postponed it exactly at this point. It was unclear what
> patches to apply, looked like some procedure/policy was needed, and I
> could not think your such a policy at that time.
>
> The idea was to check what patches are applied for each of in-debian
> architectures, and apply doc changes for all of those. This could likey be
> automated, e.g. by writing a makefile that will include debian/rules2 from
> gcc package, and then use vars set by that to print list of applied
> patches; some tricks with var-setting could do this for all archs.

Hmm, not a terrible idea.  I still think the *very* cleanest thing
would probably be to build "gcc-X.Y-doc-non-dfsg" like this, though:

 * Take the debian/ directory from "gcc-X.Y", post-processing the

> *) [minor but still] it looks a bit unfair that there is only your
> signature under README.source, while large part of the text was written by
> me :).

I agree with you that this was a very rude of the README.Debian Emacs
mode to do this. I can understand updating the date; removing your
name, not so much. Though, it also obviously shouldn't simply update
the date next to your name. So I'm not really sure what it *should*
do...

If you can think what it should do, maybe we should open a bug against
/usr/share/emacs/site-lisp/dpkg-dev-el/readme-debian.el to request the
change?

>> 2. In contemplating putting debian/copyright in DEP-5 format, I've
>> realized that I'm not sure of the exact copyright/licensing status of
>> anything in the debian/ directory, except:
>
> See debian/copyright from the old packages. Everything non-autogenerated
> under debian/ was stated to be GPL;  I don't object changing that if
> needed.

No, there's certainly no need to change that. (Of course, I would not
object if they were to be put under the Expat license. :-)

P.S.  I apologize for returning the slow response time!


--
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/cajyzjmfr77wjg6muubi6exovzpswqa7zpodl+60+uu_qsu9...@mail.gmail.com

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

[Samuel Bronson]

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 created externally-available mirror for those - please check
>> http://yoush.homelinux.org:8079/git
>>
>> Could you please clone these repos, and reformat your work into this
>> format?
>> IMO this format greatly helps to keep things consistent.
>
> I can certainly try!

Okay, I've cloned your gcc-doc repository and added my changes:

git clone https://github.com/SamB/debian-gcc-doc

(Or open it in your browser, or ...)

I'm holding off on updating the 4.4 control files and the -defaults
packages for the moment: I want to streamline the "new X.Y" process a
bit more first.

>> Maybe this could be moved to git.debian.org.

Yes, that sounds like a good idea. Then I could add the Vcs-*: fields
to debian/control. Of course, there will probably be a lot to update
in README.source then...

>> As for the rest, here are several more comments:
>>
>> *) I don't really understand the workflow of gcc-doc-non-dfgs converted to
>> 3.0 (quilt) format.
>>
>> With old format, there was debian/patches, managed by dpatch, with part of
>> patches managed by hands, and part managed by a perl script. Running the
>> script altered debian/patches/* files, including series file. But isn't
>> this unsafe for 3.0 (quilt) format since it will break metadata in .pc/
>> directory?
>
> Hmm. Perhaps the script should simply refuse to run whenever there is
> a .pc directory? (It seems that dpkg-source removes this after
> unapplying the patches.)

In any case, most of this is changed very little; the script just gets
to be a bit shorter since the patches no longer have to be shell
scripts.

>> Also, if you convert to 3.0 (quilt), why still mentioning dpatch in
>> README.source?
>
> That was an accident.

I've corrected this now.

>> *) Looks like your command line for patch convertion script is much shorter
>> that in was in previous times. How did you check which patches to apply
>> and which not?
>
> Well, I grepped the GCC package's debian/patches for anything that
> changed .texi files, and looked through the debian/rules.patch to see
> which of those seemed to be applied for Debian builds on any
> architecture (in that alternate universe where
> GFDL_INVARIANT_FREE=no).
>
>> Actually I've looked at updating gcc-doc during new year holidays, and
>> stopped and postponed it exactly at this point. It was unclear what
>> patches to apply, looked like some procedure/policy was needed, and I
>> could not think your such a policy at that time.
>>
>> The idea was to check what patches are applied for each of in-debian
>> architectures, and apply doc changes for all of those. This could likey be
>> automated, e.g. by writing a makefile that will include debian/rules2 from
>> gcc package, and then use vars set by that to print list of applied
>> patches; some tricks with var-setting could do this for all archs.
>
> Hmm, not a terrible idea.  I still think the *very* cleanest thing
> would probably be to build "gcc-X.Y-doc-non-dfsg" like this, though:

[Oops, I forgot to finish this bit:]

 * Take the debian/ directory from "gcc-X.Y"
   + uncomment the documentation patches if necessary
   + replace debian/control with one that only builds the documentation packages
   + arrange for "GFDL_INVARIANT_FREE=no" to be set
 * Put a pristine upstream tarball in the root of the tree in place of
the stripped one that gcc-X.Y uses.

(Of course, this would turn the package into little more than a script
to generate the *actual* packages.)

However, as I'm always low on diskspace, I'm a bit reluctant to
actually *try* this.

>> *) [minor but still] it looks a bit unfair that there is only your
>> signature under README.source, while large part of the text was written by
>> me :).
>
> I agree with you that this was a very rude of the README.Debian Emacs
> mode to do this. I can understand updating the date; removing your
> name, not so much. Though, it also obviously shouldn't simply update
> the date next to your name. So I'm not really sure what it *should*
> do...
>
> If you can think what it should do, maybe we should open a bug against
> /usr/share/emacs/site-lisp/dpkg-dev-el/readme-debian.el to request the
> change?
>
>>> 2. In contemplating putting debian/copyright in DEP-5 format, I've
>>> realized that I'm not sure of the exact copyright/licensing sta

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

[Samuel Thibault]

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:
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: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages gcc-4.6 depends on:
ii  binutils  2.22-5
ii  cpp-4.6   4.6.2-12
ii  gcc-4.6-base  4.6.2-12
ii  libc6 2.13-26
ii  libgcc1   1:4.7-20120129-1
ii  libgmp10  2:5.0.4+dfsg-1
ii  libgomp1  4.7-20120129-1
ii  libmpc2   0.9-4
ii  libmpfr4  3.1.0-3
ii  libquadmath0  4.7-20120129-1
ii  zlib1g1:1.2.6.dfsg-1

Versions of packages gcc-4.6 recommends:
ii  libc6-dev  2.13-26

Versions of packages gcc-4.6 suggests:
pn  binutils-gold
pn  gcc-4.6-doc  
pn  gcc-4.6-locales  
pn  gcc-4.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 faire
 RR> l'amalgame entre du bulk mail et du courrier non-solicité très ciblé
 un suppositoire non reclamé, meme tres bien ciblé, reste un suppositoire.
 -+-OS in : Guide du Neuneu d'Usenet - Plein le cul de la pub à neuneu -+-
Index: debian/patches/hurd-fixes.diff
===
--- debian/patches/hurd-fixes.diff  (révision 0)
+++ debian/patches/hurd-fixes.diff  (révision 0)
@@ -0,0 +1,11 @@
+--- a/src/libgcc/generic-morestack.c.orig  2011-12-19 21:14:52.0 
+0100
 b/src/libgcc/generic-morestack.c   2011-12-19 21:15:35.0 +0100
+@@ -507,7 +507,7 @@
+   sigemptyset (&__morestack_initial_sp.mask);
+ 
+   sigfillset (&__morestack_fullmask);
+-#ifdef __GLIBC__
++#if defined(__GLIBC__) && defined(__SIGRTMIN)
+   /* In glibc, the first two real time signals are used by the NPTL
+  threading library.  By taking them out of the set of signals, we
+  avoiding copying the signal mask in pthread_sigmask.  More
Index: debian/rules.patch
===
--- debian/rules.patch  (révision 5865)
+++ debian/rules.patch  (copie de travail)
@@ -239,7 +239,7 @@
 endif
 
 ifeq ($(DEB_TARGET_ARCH_OS),hurd)
-  debian_patches += hurd-changes
+  debian_patches += hurd-changes hurd-fixes
 endif
 
 debian_patches += gcc-ice-hack gcc-ice-apport

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

[Samuel Bronson]

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 Tracking System 


Package: sponsorship-requests
Severity: normal

Dear mentors and GCC maintainers,

I am looking for a sponsor for my package "gcc-4.6-doc-non-dfsg".

 * Package name    : gcc-4.6-doc-non-dfsg
  Version         : 4.6.2-1~naesten3
  Upstream Author : Free Software Foundation
 * URL             : http://gcc.gnu.org/
 * License         : GFDL with invariant sections
  Section         : non-free/doc

It builds these binary packages:

 cpp-4.6-doc - documentation for the GNU C preprocessor (cpp)
 gcc-4.6-doc - documentation for the GNU compilers (gcc, gobjc, g++)
 gcc-doc-base - several GNU manual pages
 gccgo-4.6-doc - documentation for the GNU Go compiler (gccgo)
 gcj-4.6-doc - documentation for the GNU Java tools (gcj, gij)
 gfortran-4.6-doc - documentation for the GNU Fortran Compiler (gfortran)
 gnat-4.6-doc - documentation for the GNU Ada 95 Compiler (gnat)

To access further information about this package, please visit the
following URL:

 http://mentors.debian.net/package/gcc-4.6-doc-non-dfsg

Alternatively, one can download the package with dget using this
command:

 dget -x 
http://mentors.debian.net/debian/pool/non-free/g/gcc-4.6-doc-non-dfsg/gcc-4.6-doc-non-dfsg_4.6.2-1~naesten3.dsc

I would be glad if someone uploaded this package for me.

Previously, it looked like Nikita V. Youshchenko was going to sponsor
the package, but he(?) turned out not to have time. See the earlier
mailing list thread for details:

 http://news.gmane.org/find-root.php?message_id=%3cE1RoTeW%2d000805%2d4f%40hydrogen%3e

Kind regards,

Samuel Bronson

--
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!


--
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/CAJYzjmeaEkTmCfN_vB58QBYZzuYDePYfBdscY4mHV5�pa...@mail.gmail.com

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

[Samuel Thibault]

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 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: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Index: debian/patches/hurd-fixes.diff
===
--- debian/patches/hurd-fixes.diff  (révision 5882)
+++ debian/patches/hurd-fixes.diff  (copie de travail)
@@ -1,11 +0,0 @@
 a/src/libgcc/generic-morestack.c.orig  2011-12-19 21:14:52.0 
+0100
-+++ b/src/libgcc/generic-morestack.c   2011-12-19 21:15:35.0 +0100
-@@ -507,7 +507,7 @@
-   sigemptyset (&__morestack_initial_sp.mask);
- 
-   sigfillset (&__morestack_fullmask);
--#ifdef __GLIBC__
-+#if defined(__GLIBC__) && defined(__SIGRTMIN)
-   /* In glibc, the first two real time signals are used by the NPTL
-  threading library.  By taking them out of the set of signals, we
-  avoiding copying the signal mask in pthread_sigmask.  More
Index: debian/rules.patch
===
--- debian/rules.patch  (révision 5882)
+++ debian/rules.patch  (copie de travail)
@@ -208,7 +208,7 @@
 endif
 
 ifeq ($(DEB_TARGET_ARCH_OS),hurd)
-  debian_patches += hurd-pthread hurd-changes hurd-fixes
+  debian_patches += hurd-pthread hurd-changes
 endif
 
 debian_patches += gcc-ice-hack gcc-ice-apport