Re: [Buildd-tools-devel] Processed: Clone and reassign to libstdc++

2009-03-23 Thread Roger Leigh 
On Mon, Mar 23, 2009 at 10:36:10AM +, Debian Bug Tracking System wrote:
> Processing commands for cont...@bugs.debian.org:
> 
> > clone 520713 -1
> Bug#520713: init script start hangs
> Bug 520713 cloned as bug 520889.
> 
> > reassign -1 libstdc++6
> Bug#520889: init script start hangs
> Bug reassigned from package `schroot' to `libstdc++6'.
> 
> > retitle -1 std::tr1::shared_ptr is broken on alpha unless code is compiled 
> > with -pthread
> Bug#520889: init script start hangs
> Changed Bug title to `std::tr1::shared_ptr is broken on alpha unless code is 
> compiled with -pthread' from `init script start hangs'.

Hi Debian GCC people,

I cloned and reassigned this to you because while I worked around this
bug in schroot, I do feel that this is fundamentally an issue in
libstdc++.

It appears from the bug investigation that the std::tr1::shared_ptr
type is using a pthread mutex for locking (which is using futexes
on the kernel side).  I'm surprised about this because I thought it
would just be using atomic increment/decrement (unless this is an
alpha-specific implementation detail), but this is not in itself
a problem.

What did surprise me is that
- my program is single threaded; it does not directly use any pthread-
  related stuff, just types from the ISO C++ Standard, and its TR1
  addendum.
- I did therefore not expect there would be a requirement to compile
  with -pthread in order to get a functional program.
- On all architectures I'm aware of other than alpha, the code works
  correctly.
- On alpha it crashes with a failed libc/libstdc++ assertion during
  object construction (where I am creating a new type instance which
  is returned contained within a shared_ptr).  The stack trace showed
  it failing in my object constructor called from my clone() method
  which returns a shared_ptr (the actual ctor is private), but the
  pthread failure subsequently points the blame at shared_ptr, since
  I'm not using any pthread stuff myself.
- One of the traces attached to the bug report shows a failure
  inside a Boost header; it's possible that it's an interaction
  between the boost and libstdc++ headers, but I can't be sure of
  that.

I have Cc'd weasel, who originally found this bug on alpha.
I don't have any alpha hardware myself, so you would probably need
to ask weasel or one of the alpha porters if you need any alpha-
specific expertise.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


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

Re: freeze exception for gcc-4.5 (i386, amd64 only)

2010-08-23 Thread Roger Leigh 
On Mon, Aug 23, 2010 at 10:03:05AM +0200, Mike Hommey wrote:
> On Mon, Aug 23, 2010 at 04:05:32AM +0200, Matthias Klose wrote:
> > On 21.08.2010 14:56, Julien Cristau wrote:
> > >On Fri, Aug 20, 2010 at 19:33:12 +0200, Arthur Loiret wrote:
> > >
> > >>Now, to be clear, what nice things would gcc-4.5 bring to our users?
> > >>There is a complete list here [0], but those ones are, in my opinion,
> > >>very nice:
> > >>  - The new link time optimiser.
> > >>  - Improved C++0x support.
> > >>  - Plugins support.
> > >>
> > >My understanding is that lto in 4.5 is not quite there yet.  Not that
> > >I've tried it or anything.
> > 
> > I don't share your understanding. I tried it for some builds.
> 
> Maybe it works on small things, but I heard it doesn't work very well
> for stuff like mozilla. 4.6 is supposed to get better.

I'm certainly concerned about issues such as #593876 where the
stricter linking breaks existing code.  I'm not sure about the
rationale for this extra strictness, but it does cause
unwanted breakage by breaking existing assumptions about
indirect linking.

Other than that, it's working fine for me.  It would be nice to
have in the release as an optional and non-default compiler for
developers who need it.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Re: DSO linking changes for wheezy

2010-11-14 Thread Roger Leigh 
On Sun, Nov 14, 2010 at 01:51:49PM +0100, Kurt Roeckx wrote:
> On Sun, Nov 07, 2010 at 04:19:10PM +0000, Roger Leigh wrote:
> > On Fri, Oct 29, 2010 at 03:43:57PM +0200, Matthias Klose wrote:
> > > For wheezy I'm planning to change the linking behaviour for DSOs (turning 
> > > on --as-needed and --no-copy-dt-needed-entries. The rationale is 
> > > summarized in http://wiki.debian.org/ToolChain/DSOLinking. I would like 
> > > to know about issues with these changes on some of the Debian ports, and 
> > > if we need to disable one of these changes on some port.
> > 
> > While I understand the rationale for --no-copy-dt-needed-entries for
> > preventing encapsulation violations via indirect linking, I don't agree
> > with the use of --as-needed *at all*.  If a library has been explicitly
> > linked in, it shouldn't be removed.  This is an issue for fixing in
> > individual packages, not in the toolchain.
> > 
> > I can understand on using it on a per-package basis, but not in the
> > actual toolchain defaults.  The compiler and linker *should not be
> > second-guessing the user*.  This can break perfectly legitimate code
> > making use of ELF constructors and other features which won't be
> > picked out just by looking at symbol usage.
> 
> People have been claiming that constructors or init section are a
> possible problem.  I have yet to see an example where it breaks.

It's not a very widely used feature.  I'm sure it's trivial to make
such a test case.  Portable software tends not to make use of ELF-
specific features like this, but that's not an excuse for breaking
perfectly legitimate code.

But whether or not there are real life examples, --as-needed is
*fundamentally wrong*.  It's deliberately *not doing what the user
requested*, and to make that misfeature the system-wide default
would be entirely inappropriate.  If a package wishes to make use
of such a feature after understanding the implications, then they
are free to do so.  But to make it the default--I don't think that's
a technically sound decision.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Re: DSO linking changes for wheezy

2010-11-14 Thread Roger Leigh 
On Sun, Nov 14, 2010 at 01:19:08PM +0100, Julien Cristau wrote:
> On Fri, Oct 29, 2010 at 15:43:57 +0200, Matthias Klose wrote:
> 
> > For wheezy I'm planning to change the linking behaviour for DSOs
> > (turning on --as-needed and --no-copy-dt-needed-entries. The
> > rationale is summarized in
> > http://wiki.debian.org/ToolChain/DSOLinking. I would like to know
> > about issues with these changes on some of the Debian ports, and if
> > we need to disable one of these changes on some port.
> > 
> --no-add-needed sounds like it'll cause a *lot* of build failures for no
> particular gain.  I don't think it's a good idea.

This change will definitely cause a lot of link failures; having some
concrete numbers to determine how many would be quite useful here, e.g.
from an archive-wide rebuild.

Example failure case:

#593876 libboost-filesystem-dev: Undeclared indirect dependency of 
boost_filesystem on boost_system causes link failure

While --no-copy-dt-needed-entries does "fix" programs depending upon
indirect linkage, this is something we've been relying on for over a
decade and has worked quite well in practice.  While strict correctness
is nice to have, and I've already fixed my programs to work with strict
linking, I'm not entirely sure why indirect linking is that bad in
practice.

Note that in the above Boost example, you get caught out just due to
some inline functions in headers resulting an a completely unexpected
additional dependency, so the need for linking is there, but would have
otherwise been happily satisfied indirectly.  Also, it means that the
user of a library needs to be intimately aware of its internals which
is not good.  If the Boost filesystem library changes how it works but
without changing its public interface, I could be screwed again in six
months time.  This is partly the fault of Boost for exposing its
internals in its headers, but disallowing indirect linking make it
worse.

Overall, it could be for the best, but it will be painful initially.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Re: DSO linking changes for wheezy

2010-11-15 Thread Roger Leigh 
On Mon, Nov 15, 2010 at 11:02:57PM +0100, Matthias Klose wrote:
> On 14.11.2010 16:06, Roger Leigh wrote:
>>>> While I understand the rationale for --no-copy-dt-needed-entries for
>>>> preventing encapsulation violations via indirect linking, I don't agree
>>>> with the use of --as-needed *at all*.  If a library has been explicitly
>>>> linked in, it shouldn't be removed.  This is an issue for fixing in
>>>> individual packages, not in the toolchain.
>>>>
>>>> I can understand on using it on a per-package basis, but not in the
>>>> actual toolchain defaults.  The compiler and linker *should not be
>>>> second-guessing the user*.  This can break perfectly legitimate code
>>>> making use of ELF constructors and other features which won't be
>>>> picked out just by looking at symbol usage.
>>>
>>> People have been claiming that constructors or init section are a
>>> possible problem.  I have yet to see an example where it breaks.
>>
>> It's not a very widely used feature.  I'm sure it's trivial to make
>> such a test case.  Portable software tends not to make use of ELF-
>> specific features like this, but that's not an excuse for breaking
>> perfectly legitimate code.
>>
>> But whether or not there are real life examples, --as-needed is
>> *fundamentally wrong*.  It's deliberately *not doing what the user
>> requested*, and to make that misfeature the system-wide default
>> would be entirely inappropriate.  If a package wishes to make use
>> of such a feature after understanding the implications, then they
>> are free to do so.  But to make it the default--I don't think that's
>> a technically sound decision.
>
> maybe, and fix it in N - ~100 packages?  Or fix the ~100 packages?  The 
> point of injection is for discussion.  I would prefer having this set in 
> dpkg-buildflags, and then disabled by these ~100 packages.  Note that 
> this is probably the same like modifying the N - ~100 packages, as almost 
> no package respects dpkg-buildflags yet.

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.

Other libraries being linked unnecessarily can be removed on a
per-package basis.  lintian is warning about this, so most developers
should be aware of the problem.

Damaging our toolchain to work around buggy build scripts is wrong; we
should just fix the scripts!


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Re: DSO linking changes for wheezy

2010-11-16 Thread Roger Leigh 
On Tue, Nov 16, 2010 at 01:14:09AM +0100, Matthias Klose wrote:
> On 14.11.2010 13:19, Julien Cristau wrote:
>> On Fri, Oct 29, 2010 at 15:43:57 +0200, Matthias Klose wrote:
>>
>>> For wheezy I'm planning to change the linking behaviour for DSOs
>>> (turning on --as-needed and --no-copy-dt-needed-entries. The
>>> rationale is summarized in
>>> http://wiki.debian.org/ToolChain/DSOLinking. I would like to know
>>> about issues with these changes on some of the Debian ports, and if
>>> we need to disable one of these changes on some port.
>>>
>> --no-add-needed sounds like it'll cause a *lot* of build failures for no
>> particular gain.  I don't think it's a good idea.
>
> I think it is. Besides fixing potential bugs, else you'll never be able 
> to use gold as the linker. See the already filed bug reports.

This change is one I can agree with on technical grounds, though it
will cause a great deal of pain in the short term.  Have we got any
estimates on exactly how much breakage will result before the change
gets made?


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Re: DSO linking changes for wheezy

2010-11-16 Thread Roger Leigh 
On Tue, Nov 16, 2010 at 07:04:53PM +0100, Matthias Klose wrote:
> On 16.11.2010 10:42, Roger Leigh wrote:
>> On Tue, Nov 16, 2010 at 01:14:09AM +0100, Matthias Klose wrote:
>>> On 14.11.2010 13:19, Julien Cristau wrote:
>>>> On Fri, Oct 29, 2010 at 15:43:57 +0200, Matthias Klose wrote:
>>>>
>>>>> For wheezy I'm planning to change the linking behaviour for DSOs
>>>>> (turning on --as-needed and --no-copy-dt-needed-entries. The
>>>>> rationale is summarized in
>>>>> http://wiki.debian.org/ToolChain/DSOLinking. I would like to know
>>>>> about issues with these changes on some of the Debian ports, and if
>>>>> we need to disable one of these changes on some port.
>>>>>
>>>> --no-add-needed sounds like it'll cause a *lot* of build failures for no
>>>> particular gain.  I don't think it's a good idea.
>>>
>>> I think it is. Besides fixing potential bugs, else you'll never be able
>>> to use gold as the linker. See the already filed bug reports.
>>
>> This change is one I can agree with on technical grounds, though it
>> will cause a great deal of pain in the short term.  Have we got any
>> estimates on exactly how much breakage will result before the change
>> gets made?
>
> see http://wiki.debian.org/ToolChain/DSOLinking#Furtherinformation
> referenced in the first email of this thread.

I had a look at that, and we've got (summarised)

413 outstanding bugs
308 fixed/pending

So there's still some way to go, but looking promising.  I did notice
that all those bugs were filed almost exactly a year ago.  This won't
have picked up issues with current packages, such as the Boost link
failures I've encountered.  Would it be possible to repeat the
archive-wide rebuild with our current sources?


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?   http://gutenprint.sourceforge.net/
   `-GPG Public Key: 0x25BFB848   Please GPG sign your mail.


signature.asc
Description: Digital signature

Re: Bug in gcc for powerpc?

2012-07-28 Thread Roger Leigh 
On Sat, Jul 28, 2012 at 04:45:35PM -0400, Felipe Sateler wrote:
> Hi gcc and powerpc teams,
> 
> Supercollider recently failed to build in powerpc[1] with some weird
> errors about operand out of range. Googling around suggests working
> around the problem by avoiding inlining. And in fact, SC builds after
> avoiding inlining one function. However, it seems to me this is a bug
> in gcc, since it shouldn't ouptut invalid assembler. I'm not quite
> sure how to handle this sort of bug, however. Where should I file this
> bug (that is, which package)? This bug seems to have happened a few
> times already, so I'm not quite sure if this is supposed to be fixed
> or not.

Just as a data point, I've reproduced this identically on current
unstable (powerpc).  Have you tried using a different compiler
version e.g. 4.7?  I can do further investigation tomorrow if you
would like.

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
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/20120729003423.gb25...@codelibre.net

Re: Bug in gcc for powerpc?

2012-07-30 Thread Roger Leigh 
On Sat, Jul 28, 2012 at 08:43:16PM -0400, Felipe Sateler wrote:
> On Sat, Jul 28, 2012 at 8:34 PM, Roger Leigh  wrote:
> > On Sat, Jul 28, 2012 at 04:45:35PM -0400, Felipe Sateler wrote:
> >> Hi gcc and powerpc teams,
> >>
> >> Supercollider recently failed to build in powerpc[1] with some weird
> >> errors about operand out of range. Googling around suggests working
> >> around the problem by avoiding inlining. And in fact, SC builds after
> >> avoiding inlining one function. However, it seems to me this is a bug
> >> in gcc, since it shouldn't ouptut invalid assembler. I'm not quite
> >> sure how to handle this sort of bug, however. Where should I file this
> >> bug (that is, which package)? This bug seems to have happened a few
> >> times already, so I'm not quite sure if this is supposed to be fixed
> >> or not.
> >
> > Just as a data point, I've reproduced this identically on current
> > unstable (powerpc).  Have you tried using a different compiler
> > version e.g. 4.7?  I can do further investigation tomorrow if you
> > would like.
> 
> I am testing on partch, I don't have access to other ppc hardware.
> Partch has gcc 4.4 and 4.6, it fails with both, with the same error
> but in different places (4.4 has lots of errors, 4.6 just 2).

I can give you access to a G4 ppc running current testing with
build chroots available on it if you would find that useful.  The
only thing is that you'll need IPv6 to access it.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
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/20120730210921.gg25...@codelibre.net

Re: Bug in gcc for powerpc?

2012-07-31 Thread Roger Leigh 
On Tue, Jul 31, 2012 at 09:39:58AM -0400, Felipe Sateler wrote:
> On Mon, Jul 30, 2012 at 5:09 PM, Roger Leigh  wrote:
> > On Sat, Jul 28, 2012 at 08:43:16PM -0400, Felipe Sateler wrote:
> >> On Sat, Jul 28, 2012 at 8:34 PM, Roger Leigh  wrote:
> >> > On Sat, Jul 28, 2012 at 04:45:35PM -0400, Felipe Sateler wrote:
> >> >> Hi gcc and powerpc teams,
> >> >>
> >> >> Supercollider recently failed to build in powerpc[1] with some weird
> >> >> errors about operand out of range. Googling around suggests working
> >> >> around the problem by avoiding inlining. And in fact, SC builds after
> >> >> avoiding inlining one function. However, it seems to me this is a bug
> >> >> in gcc, since it shouldn't ouptut invalid assembler. I'm not quite
> >> >> sure how to handle this sort of bug, however. Where should I file this
> >> >> bug (that is, which package)? This bug seems to have happened a few
> >> >> times already, so I'm not quite sure if this is supposed to be fixed
> >> >> or not.
> >> >
> >> > Just as a data point, I've reproduced this identically on current
> >> > unstable (powerpc).  Have you tried using a different compiler
> >> > version e.g. 4.7?  I can do further investigation tomorrow if you
> >> > would like.
> >>
> >> I am testing on partch, I don't have access to other ppc hardware.
> >> Partch has gcc 4.4 and 4.6, it fails with both, with the same error
> >> but in different places (4.4 has lots of errors, 4.6 just 2).
> >
> > I can give you access to a G4 ppc running current testing with
> > build chroots available on it if you would find that useful.e  The
> > only thing is that you'll need IPv6 to access it.
> 
> I don't think it'd be useful. I definitely do not have the expertise
> to debug gcc.

No worries.

I just did a repeat build on it, not with sbuild, but in a cloned
chroot, and it built successfully.  So it looks like whatever it is,
it's somewhat intermittent.  I would suspect GCC; unlikely to be
hardware.

I'll try doing a binary-only NMU build with sbuild (á la the buildds),
and if that also succeeds, I'll upload it.  If I can reproduce the
failure, I'll see if I can dump the preprocessed source and make a
testcase; but given the elusive nature of the bug this might not be
possible.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
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/20120731224700.gm25...@codelibre.net

Re: Bug in gcc for powerpc?

2012-07-31 Thread Roger Leigh 
On Tue, Jul 31, 2012 at 11:47:00PM +0100, Roger Leigh wrote:
> On Tue, Jul 31, 2012 at 09:39:58AM -0400, Felipe Sateler wrote:
> > On Mon, Jul 30, 2012 at 5:09 PM, Roger Leigh  wrote:
> > > On Sat, Jul 28, 2012 at 08:43:16PM -0400, Felipe Sateler wrote:
> > >> On Sat, Jul 28, 2012 at 8:34 PM, Roger Leigh  
> > >> wrote:
> > >> > On Sat, Jul 28, 2012 at 04:45:35PM -0400, Felipe Sateler wrote:
> > >> >> Hi gcc and powerpc teams,
> > >> >>
> > >> >> Supercollider recently failed to build in powerpc[1] with some weird
> > >> >> errors about operand out of range. Googling around suggests working
> > >> >> around the problem by avoiding inlining. And in fact, SC builds after
> > >> >> avoiding inlining one function. However, it seems to me this is a bug
> > >> >> in gcc, since it shouldn't ouptut invalid assembler. I'm not quite
> > >> >> sure how to handle this sort of bug, however. Where should I file this
> > >> >> bug (that is, which package)? This bug seems to have happened a few
> > >> >> times already, so I'm not quite sure if this is supposed to be fixed
> > >> >> or not.
> > >> >
> > >> > Just as a data point, I've reproduced this identically on current
> > >> > unstable (powerpc).  Have you tried using a different compiler
> > >> > version e.g. 4.7?  I can do further investigation tomorrow if you
> > >> > would like.
> > >>
> > >> I am testing on partch, I don't have access to other ppc hardware.
> > >> Partch has gcc 4.4 and 4.6, it fails with both, with the same error
> > >> but in different places (4.4 has lots of errors, 4.6 just 2).
> > >
> > > I can give you access to a G4 ppc running current testing with
> > > build chroots available on it if you would find that useful.e  The
> > > only thing is that you'll need IPv6 to access it.
> > 
> > I don't think it'd be useful. I definitely do not have the expertise
> > to debug gcc.
> 
> I'll try doing a binary-only NMU build with sbuild (á la the buildds),
> and if that also succeeds, I'll upload it.  If I can reproduce the
> failure, I'll see if I can dump the preprocessed source and make a
> testcase; but given the elusive nature of the bug this might not be
> possible.

Hmm, I see 1:3.5.3~repack-3 has built successfully over two days ago.
Did you find out what the problem was here?


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linuxhttp://people.debian.org/~rleigh/
 `. `'   schroot and sbuild  http://alioth.debian.org/projects/buildd-tools
   `-GPG Public Key  F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800


-- 
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/20120731225648.gn25...@codelibre.net

Bug#373937: libstdc++6: codecvt locale facet is broken

2006-06-16 Thread Roger Leigh 
Package: libstdc++6
Version: 4.1.1-5
Severity: important

The attached source file (UTF-8 encoded) demonstrates that codecvt
is broken for the simplest of transformations (UTF-8 to UCS-4).
This is pretty basic, and the underlying gconf stuff works correctly,
so the bug is either in libstdc++6 or somewhere inline in the headers.

$ ./wide
wide: ../iconv/loop.c:425: utf8_internal_loop_single: Assertion `inptr -
bytebuf > (state->__count & 7)' failed.
Aborted

While running:
(gdb) bt
#0  0x0fcc672c in __gconv_transform_utf8_internal () from /lib/tls/libc.so.6
#1  0x0fe0425c in ?? () from /lib/tls/libc.so.6
#2  0x0ffa6ef8 in std::codecvt::do_in ()
   from /usr/lib/libstdc++.so.6
#3  0x100016b4 in std::__codecvt_abstract_base::in
(this=0x100290b8, [EMAIL PROTECTED], __from=0x10013014 "[EMAIL PROTECTED]",
__from_end=0x1001301d "", [EMAIL PROTECTED], __to=0x7fa405bc,
__to_end=0x7fa406fc, [EMAIL PROTECTED])
at 
/usr/lib/gcc/powerpc-linux-gnu/4.1.2/../../../../include/c++/4.1.2/bits/codecvt.h:204
#4  0x10001244 in to_wide_string ([EMAIL PROTECTED], [EMAIL PROTECTED])
at wide.cc:22
#5  0x10001544 in main () at wide.cc:59

After aborting:
wide: ../iconv/loop.c:425: utf8_internal_loop_single: Assertion `inptr - 
bytebuf > (state->__count & 7)' failed.

Program received signal SIGABRT, Aborted.
0x0fcd67bc in raise () from /lib/tls/libc.so.6
(gdb) bt
#0  0x0fcd67bc in raise () from /lib/tls/libc.so.6
#1  0x0fcd82c0 in abort () from /lib/tls/libc.so.6
#2  0x0fcce768 in __assert_fail () from /lib/tls/libc.so.6
#3  0x0fcc6c7c in __gconv_transform_utf8_internal () from /lib/tls/libc.so.6
#4  0x0fcc6c7c in __gconv_transform_utf8_internal () from /lib/tls/libc.so.6
#5  0x0fcc6c7c in __gconv_transform_utf8_internal () from /lib/tls/libc.so.6
#6  0x0fcc6c7c in __gconv_transform_utf8_internal () from /lib/tls/libc.so.6
#7  0x0fcc6c7c in __gconv_transform_utf8_internal () from /lib/tls/libc.so.6
#8  0x0fcc6c7c in __gconv_transform_utf8_internal () from /lib/tls/libc.so.6
#9  0x0fcc6c7c in __gconv_transform_utf8_internal () from /lib/tls/libc.so.6
#10 0x0fcc6c7c in __gconv_transform_utf8_internal () from /lib/tls/libc.so.6
#11 0x0fcc6c7c in __gconv_transform_utf8_internal () from /lib/tls/libc.so.6
Previous frame inner to this frame (corrupt stack?)


Regards,
Roger

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (990, 'unstable')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.16.17
Locale: LANG=en_GB.UTF8, LC_CTYPE=en_GB.UTF8 (charmap=UTF-8)

Versions of packages libstdc++6 depends on:
ii  gcc-4.1-base  4.1.1-5The GNU Compiler Collection (base 
ii  libc6 2.3.6-15   GNU C Library: Shared libraries
ii  libgcc1   1:4.1.1-5  GCC support library

libstdc++6 recommends no packages.

-- no debconf information
#include 
#include 
#include 

std::wstring
to_wide_string (std::string const& str,
		std::localelocale)
{
  typedef std::codecvt codecvt_type;
  codecvt_type const& cvt = std::use_facet(locale);
  mbstate_t state;
  const char *cbegin = str.data(), *cend = str.data() + str.size(), *cnext;
  wchar_t *wcnext;
  wchar_t wcbuf[80];
  std::wstring ret;

  while (1)
{
  std::codecvt_base::result res =
	cvt.in(state,
	   cbegin, cend, cnext,
	   wcbuf, wcbuf + (sizeof(wcbuf) / sizeof(wcbuf[0])), wcnext);

  if (res == std::codecvt_base::ok || std::codecvt_base::partial)
	{
	  std::cout << "1" << std::endl;
	  ret += std::wstring(wcbuf, wcnext);
	  if (cend == cnext)
	break;
	}
  else if (res == std::codecvt_base::noconv)
	{
	  std::cout << "2" << std::endl;
	  ret += std::wstring(cbegin, cend);
	  break;
	}
  else if (res == std::codecvt_base::error)
	{
	  std::cout << "3" << std::endl;
	  break;
	}
  else
	break;

  std::cout << "4" << std::endl;
  cbegin = cnext;
}

  return ret;
}

int main()
{
  std::locale::global(std::locale(""));
  std::cout.imbue(std::locale());
  std::wcerr.imbue(std::locale());

  std::string foo = "fffäß»";
  std::wstring wfoo = to_wide_string(foo, std::wcerr.getloc());

  std::cout << foo;
  std::wcerr << wfoo;

  return 0;
}

Bug#373937: Acknowledgement (libstdc++6: codecvt locale facet is broken)

2006-06-16 Thread Roger Leigh 
Reported upstream as

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28059


Note this affects GCC versions 3.3, 4.0, 4.1 and 4.2.  It works
correctly in 3.4.


Regards,
Roger

-- 
Roger Leigh
Printing on GNU/Linux?  http://gutenprint.sourceforge.net/
Debian GNU/Linuxhttp://www.debian.org/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.


pgpBeyQoH6rzG.pgp
Description: PGP signature

Bug#373937: Acknowledgement (libstdc++6: codecvt locale facet is broken)

2006-06-16 Thread Roger Leigh 
I have attached two additional testcases to the upstream bug report.
The testcases are now:

Testcase to show codecvt crash
http://gcc.gnu.org/bugzilla/attachment.cgi?id=11679 (wide.cc)

Use mbsnrtowcs directly.
http://gcc.gnu.org/bugzilla/attachment.cgi?id=11682 (wide2.cc)

C example using mbsnrtowcs
http://gcc.gnu.org/bugzilla/attachment.cgi?id=11683 (wide3.c)


There isn't a clear pattern here.  It's possible that the testcases
are buggy, but's it's odd how they work on one arch and not the other,
or vice versa.


Regards,
Roger

-- 
Roger Leigh
Printing on GNU/Linux?  http://gutenprint.sourceforge.net/
Debian GNU/Linuxhttp://www.debian.org/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.


pgprvlhYHTkKZ.pgp
Description: PGP signature

Bug#389215: gij: Please Provide java2-runtime

2006-09-24 Thread Roger Leigh 
Package: gij
Version: 4:4.1.1-7
Severity: normal

Hi,

gij has the following Provides:

  Provides: java-runtime, java1-runtime, java-virtual-machine

Its depdendency, gij-4.1, has these Provides:

  Provides: java-virtual-machine, java2-runtime, java1-runtime, java-runtime

Please could you also Provide java2-runtime to correct the dependencies?


Thanks,
Roger

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (990, 'unstable')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-1-powerpc
Locale: LANG=en_GB.UTF8, LC_CTYPE=en_GB.UTF8 (charmap=UTF-8)


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

Bug#345550: g++-4.0: Fails to compile C++ with -frepo

2006-01-01 Thread Roger Leigh 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

This has been reported upstream as GCC Bugzilla #25625:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25625


Regards,
Roger

- -- 
Roger Leigh
Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
Debian GNU/Linuxhttp://www.debian.org/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFDuBt+VcFcaSW/uEgRAgowAKDwms09xfVUXJ+qDR+If1H1T0RqxwCfdud0
kzVZurCumuSBAqU/xthpGUs=
=KAyU
-END PGP SIGNATURE-


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

Bug#345550: g++-4.0: Fails to compile C++ with -frepo

2006-01-01 Thread Roger Leigh 
Package: g++-4.0
Version: 4.0.2-5
Severity: normal

Hi, given this trivial C++ code:

#include 
#include 

int main(void)
{
  std::cout << boost::format("Hello %1%!\n%2%\n") % "world" % 343
<< std::flush;
  return 0;
}

It fails to compile:

$ g++ -frepo -c test.cc
/usr/include/boost/mpl/aux_/integral_wrapper.hpp: In instantiation of 
‘mpl_::integral_c’:
/usr/include/boost/type_traits/integral_constant.hpp:21:   instantiated from 
‘boost::integral_constant’
/usr/include/boost/type_traits/alignment_of.hpp:81:   instantiated from here
/usr/include/boost/mpl/aux_/integral_wrapper.hpp:72: error: ‘(((unsigned 
int)mpl_::integral_c::value) + 1u)’ is not a valid template 
argument for type ‘unsigned int’ because it is a non-constant expression
/usr/include/boost/mpl/aux_/integral_wrapper.hpp: In instantiation of 
‘mpl_::integral_c’:
/usr/include/boost/type_traits/integral_constant.hpp:21:   instantiated from 
‘boost::integral_constant’
/usr/include/boost/type_traits/alignment_of.hpp:81:   instantiated from here
/usr/include/boost/mpl/aux_/integral_wrapper.hpp:73: error: ‘(((unsigned 
int)mpl_::integral_c::value) - 1u)’ is not a valid template 
argument for type ‘unsigned int’ because it is a non-constant expression
/usr/include/boost/mpl/aux_/integral_wrapper.hpp: In instantiation of 
‘mpl_::int_<3>’:
/usr/include/boost/mpl/if.hpp:131:   instantiated from here
/usr/include/boost/mpl/aux_/integral_wrapper.hpp:72: error: 
‘(((int)mpl_::int_<3>::value) + 1)’ is not a valid template argument for type 
‘int’ because it is a non-constant expression
/usr/include/boost/mpl/aux_/integral_wrapper.hpp: In instantiation of 
‘mpl_::int_<3>’:
/usr/include/boost/mpl/if.hpp:131:   instantiated from here
/usr/include/boost/mpl/aux_/integral_wrapper.hpp:73: error: 
‘(((int)mpl_::int_<3>::value) - 1)’ is not a valid template argument for type 
‘int’ because it is a non-constant expression
/usr/include/boost/mpl/aux_/integral_wrapper.hpp: In instantiation of 
‘mpl_::int_<-0x1>’:
/usr/include/boost/mpl/if.hpp:131:   instantiated from here
/usr/include/boost/mpl/aux_/integral_wrapper.hpp:72: error: 
‘(((int)mpl_::int_<-0x1>::value) + 1)’ is not a valid template 
argument for type ‘int’ because it is a non-constant expression
/usr/include/boost/mpl/aux_/integral_wrapper.hpp: In instantiation of 
‘mpl_::int_<-0x1>’:
/usr/include/boost/mpl/if.hpp:131:   instantiated from here
/usr/include/boost/mpl/aux_/integral_wrapper.hpp:73: error: 
‘(((int)mpl_::int_<-0x1>::value) - 1)’ is not a valid template 
argument for type ‘int’ because it is a non-constant expression
/usr/include/boost/mpl/aux_/integral_wrapper.hpp: In instantiation of 
‘mpl_::int_<1>’:
/usr/include/boost/mpl/not.hpp:47:   instantiated from here
/usr/include/boost/mpl/aux_/integral_wrapper.hpp:72: error: 
‘(((int)mpl_::int_<1>::value) + 1)’ is not a valid template argument for type 
‘int’ because it is a non-constant expression
/usr/include/boost/mpl/aux_/integral_wrapper.hpp: In instantiation of 
‘mpl_::int_<1>’:
/usr/include/boost/mpl/not.hpp:47:   instantiated from here
/usr/include/boost/mpl/aux_/integral_wrapper.hpp:73: error: 
‘(((int)mpl_::int_<1>::value) - 1)’ is not a valid template argument for type 
‘int’ because it is a non-constant expression
/usr/include/boost/mpl/if.hpp: In instantiation of 
‘boost::mpl::if_, 
boost::optional_detail::types_when_is_ref, 
boost::optional_detail::types_when_isnt_ref >’:
/usr/include/boost/optional/optional.hpp:152:   instantiated from 
‘boost::optional_detail::optional_base’
/usr/include/boost/optional/optional.hpp:407:   instantiated from 
‘boost::optional’
/usr/include/boost/format/internals.hpp:56:   instantiated from here
/usr/include/boost/mpl/if.hpp:67: error: ‘mpl_::bool_::value’ is not a 
valid template argument for type ‘bool’ because it is a non-constant expression
/usr/include/boost/mpl/if.hpp: In instantiation of 
‘boost::mpl::if_, 
boost::optional_detail::types_when_is_ref, 
boost::optional_detail::types_when_isnt_ref >’:
/usr/include/boost/optional/optional.hpp:152:   instantiated from 
‘boost::optional_detail::optional_base’
/usr/include/boost/optional/optional.hpp:407:   instantiated from 
‘boost::optional’
/usr/include/boost/format/internals.hpp:56:   instantiated from here
/usr/include/boost/mpl/if.hpp:70: error: ‘mpl_::bool_::value’ is not a 
valid template argument for type ‘bool’ because it is a non-constant expression
/usr/include/boost/mpl/aux_/integral_wrapper.hpp: In instantiation of 
‘mpl_::integral_c’:
/usr/include/boost/type_traits/integral_constant.hpp:21:   instantiated from 
‘boost::integral_constant’
/usr/include/boost/type_traits/alignment_of.hpp:61:   instantiated from 
‘boost::alignment_of’
/usr/include/boost/optional/optional.hpp:97:   instantiated from 
‘boost::optional_detail::aligned_storage::dummy_u’
/usr/include/boost/optional/optional.hpp:98:   instantiated from 
‘boost::optional_detail::aligned_storage’
/usr/includ

Bug#345821: libstdc++6: Documentation bug in ext/stdio_filebuf.h

2006-01-03 Thread Roger Leigh 
Package: libstdc++6
Version: 4.0.2-5
Severity: normal

Using libstdc++, I've got code like this:

  __gnu_cxx::stdio_filebuf fdbuf(fd, std::ios::in);

The doxygen docs for this fd ctor say "The file descriptor will be
automatically closed when the stdio_filebuf is closed/destroyed.", but I
appear to be leaking fds due to making the assumption I was passing
ownership of the fd to this streambuf, and not closing it by hand.

Is this a documentation bug?

I've checked , and I can't see any referece to
close().  The docs for the FILE* ctor say " The FILE* will **not** be
automatically closed when the stdio_filebuf is closed/destroyed.", so it
looks like the docs are wrong in this case.

If this is true, just adding "not" should fix it:

-- System Information:
--- stdio_filebuf.h.old 2006-01-03 18:49:58.653951737 +
+++ stdio_filebuf.h 2006-01-03 18:50:31.536432330 +
@@ -72,7 +72,7 @@
*  @param  size  Optimal or preferred size of internal buffer, in chars.
*
*  This constructor associates a file stream buffer with an open
-   *  POSIX file descriptor. The file descriptor will be automatically
+   *  POSIX file descriptor. The file descriptor will not be automatically
*  closed when the stdio_filebuf is closed/destroyed.
   */
   stdio_filebuf(int __fd, std::ios_base::openmode __mode,

I also filed this upstream
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25653).


Regards,
Roger


Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (990, 'unstable')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)

Versions of packages libstdc++6 depends on:
ii  gcc-4.0-base  4.0.2-5The GNU Compiler Collection (base 
ii  libc6 2.3.5-10   GNU C Library: Shared libraries an
ii  libgcc1   1:4.0.2-5  GCC support library

libstdc++6 recommends no packages.

-- no debconf information


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

Bug#345550: Bug #345550 g++-4.0: Fails to compile C++ with -frepo

2006-01-04 Thread Roger Leigh 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

tags 345550 + fixed-upstream
thanks

This was fixed upstream (SVN changesets 109305, 109306 and 109307) for
the 4.0.3 release.


Regards,
Roger

- -- 
Roger Leigh
Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
Debian GNU/Linuxhttp://www.debian.org/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFDu6L2VcFcaSW/uEgRApSuAJ0RHo3eomfib+2MRURw7vULmHSL8ACg1/PD
rvTWvdpG9PshB2CUisIyiB4=
=ZO17
-END PGP SIGNATURE-


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

Bug#424896: libstdc++6-4.2-doc: Missing conflict with libstdc++6-4.1-doc makes package uninstallable

2007-05-17 Thread Roger Leigh 
Package: libstdc++6-4.2-doc
Version: 4.2-20070516-1
Severity: serious
Justification: Won't install due to duplicate files from libstdc++6-4.1-doc

Unpacking libstdc++6-4.2-doc (from
.../libstdc++6-4.2-doc_4.2-20070516-1_all.deb) ...
dpkg: error processing
/var/cache/apt/archives/libstdc++6-4.2-doc_4.2-20070516-1_all.deb
(--unpack):
 trying to overwrite
`/usr/share/man/man3/std::tr1::_Derives_from_binary_function.3.gz',
which is also in package libstdc++6-4.1-doc
dpkg-deb: subprocess paste killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/libstdc++6-4.2-doc_4.2-20070516-1_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

Changing
Conflicts: libstdc++5-doc, libstdc++5-3.3-doc, libstdc++6-doc, 
libstdc++6-4.0-doc
to
Conflicts: libstdc++5-doc, libstdc++5-3.3-doc, libstdc++6-doc, 
libstdc++6-4.0-doc, libstdc++6-4.1-doc

should fix this.


Regards,
Roger

-- System Information:
Debian Release: lenny/sid
  APT prefers unstable
  APT policy: (990, 'unstable')
Architecture: powerpc (ppc)

Kernel: Linux 2.6.18-3-powerpc
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libstdc++6-4.2-doc depends on:
ii  gcc-4.2-base  4.2-20070516-1 The GNU Compiler Collection (base 

libstdc++6-4.2-doc recommends no packages.


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

Bug#307111: gcc-4.0: Missing lsb-release build dependency

2005-04-30 Thread Roger Leigh 
Package: gcc-4.0
Version: 4.0.0-1
Severity: serious
Tags: experimental
Justification: no longer builds from source

[EMAIL PROTECTED]:/tmp/gccbuild/gcc-4.0-4.0.0$ time debuild -uc -us
dpkg-buildpackage: source package is gcc-4.0
dpkg-buildpackage: source version is 4.0.0-1
dpkg-buildpackage: host architecture is powerpc
 fakeroot debian/rules clean
 /bin/bash: lsb_release: command not found
 rm -rf stamps
 rm -rf gcc-4.0.0 gpc-20030830 p
 /usr/bin/make -f debian/rules2 clean
 /bin/bash: lsb_release: command not found

lsb_release is missing.  The lsb-release package might need adding
to the Build-Depends.


Regards,
Roger


-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (990, 'unstable')
Architecture: powerpc (ppc)
Kernel: Linux 2.6.11.7
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)


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

gcc build log: 4.0.0-1 on powerpc-unknown-linux-gnu

2005-05-01 Thread Roger Leigh 
one)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name   VersionDescription
+++-==-==-
ii  binutils   2.15-5 The GNU assembler, linker and binary utiliti
ii  libc6-dev  2.3.2.ds1-21   GNU C Library: Development Libraries and Hea


Patches that Debian applied in this version:

gcc-version:
  Add "(Debian )" to the gcc version string

gcc-textdomain:
  Set gettext's domain and textdomain to the versioned package name.

rename-info-files:
  Allow transformations on info file names. Reference the
  transformed info file names in the texinfo files.

libstdc++-pic:
  Build and install libstdc++_pic.a library.

libstdc++-doclink:
  adjust hrefs to point to the local documentation

amd64-specs:
  On x86-64 use 64bits mode assembly except with -m32.

gccbug:
  Use sensible-editor instead of vi as fallback editor

gccbug-posix:
  Make gccbug POSIX compliant (patch by David Weinehall)
  http://www.opengroup.org/onlinepubs/009695399/utilities/test.html

boehm-gc-nocheck:
  Disable the boehm-gc testsuite. Hangs forever on this architecture

acats-expect:
  Run the ACATS testsuite using expect

fastjar-version:
  Append GCC version to the fastjar version string.

libstdc++-doxygen:
  libstdc++ doxygen docs: Set SHORT_NAMES to YES

pr19769:
  Temporary fix for gdb, dwarf2 and libjava per

deb-protoize:
  build protoize/unprotoize binaries

ada-link-lib:
  - Install the shared Ada libraries as '.so.1', not '.so' to conform
  to the Debian policy.
  - Don't include a runtime link path (-rpath), when linking binaries.
  - Build the shared libraries on hppa-linux.

ada-gcc-name:
  use gcc-4.0 instead of gcc as the command name.

link-libs:

reporting:
  Add Debian URL for bug reporting isntructions.

Counting all warnings,
there are 41 warnings in stage3 of this bootstrap.

Number of warnings per file:
 11 treelang/lex.c
  7 /usr/share/bison/bison.simple
  6 gcc/config/rs6000/altivec.md
  5 gcc/gcc.c
  3 gengtype-lex.c
  2 gcc/objc/lang-specs.h
  1 gcc/treelang/parse.y
  1 gcc/protoize.c
  1 gcc/java/jvspec.c
  1 gcc/fortran/trans-common.c
  1 gcc/fortran/simplify.c
  1 gcc/fortran/resolve.c
  1 gcc/fortran/expr.c

Number of warning types:
  8 old-style function definition
  4 operand 3 missing mode?
  4 control may reach end of non-void function â__gmpz_get_uiâ being 
inlined
  2 operand 1 missing mode?
  2 label âyyoverflowlabâ defined but not used
  1 string length â844â is greater than the length â509â ISO C89 
compilers are required to support
  1 string length â834â is greater than the length â509â ISO C89 
compilers are required to support
  1 string length â791â is greater than the length â509â ISO C89 
compilers are required to support
  1 string length â783â is greater than the length â509â ISO C89 
compilers are required to support
  1 string length â692â is greater than the length â509â ISO C89 
compilers are required to support
  1 string length â643â is greater than the length â509â ISO C89 
compilers are required to support
  1 string length â608â is greater than the length â509â ISO C89 
compilers are required to support
  1 string length â1148â is greater than the length â509â ISO C89 
compilers are required to support
  1 no previous prototype for âyyset_outâ
  1 no previous prototype for âyyset_linenoâ
  1 no previous prototype for âyyset_inâ
  1 no previous prototype for âyyset_debugâ
  1 no previous prototype for âyylex_destroyâ
  1 no previous prototype for âyyget_textâ
  1 no previous prototype for âyyget_outâ
  1 no previous prototype for âyyget_linenoâ
  1 no previous prototype for âyyget_lengâ
  1 no previous prototype for âyyget_inâ
  1 no previous prototype for âyyget_debugâ
  1 control may reach end of non-void function âcheck_type_matchâ being 
inlined
  1 argument âclean_text_pâ might be clobbered by âlongjmpâ or 
âvforkâ
END test-summary

-- 
Roger Leigh
Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
Debian GNU/Linuxhttp://www.debian.org/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.

Bug#309708: libgcc1 shlibs are Ubuntu-specific

2005-05-18 Thread Roger Leigh 
Package: libgcc1
Version: 1:4.0.0-1
Severity: grave
Tags: experimental
Justification: renders package unusable in Debian

$ cat /var/lib/dpkg/info/libgcc1.shlibs
libgcc_s 1 libgcc1 (>= 1:4.0-0pre6ubuntu4)

I noticed this when checking a package I NMU'd:
http://packages.qa.debian.org/s/scite.html
# scite/powerpc unsatisfiable Depends: libgcc1 (>= 1:4.0-0pre6ubuntu4)

This is the unstable version:
$ cat /var/lib/dpkg/info/libgcc1.shlibs
libgcc_s 1 libgcc1 (>= 1:3.4.1-3)

The ubuntu-specific version should not be in Debian.


Regards,
Roger

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (990, 'unstable')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-rc4
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)

Versions of packages libgcc1 depends on:
ii  libc6   2.3.2.ds1-22 GNU C Library: Shared libraries an

-- no debconf information


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

gcc-4.0 build problems on powerpc

2005-05-21 Thread Roger Leigh 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi folks,

I found quite a number of errors, many minor, some serious, building
4.0.0-7, in both the gcc build and while packaging.  I've put all the
detail in bug #309986.


Regards,
Roger


[PS.  I'm not subscribed to debian-gcc, so I'd appreciate a CC on any
replies.  Thanks.]

- -- 
Roger Leigh
Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
Debian GNU/Linuxhttp://www.debian.org/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iD8DBQFCjvYuVcFcaSW/uEgRAoq6AJ0d49+um45j8I4oP/zRRY9Qr8HUvQCgsuEA
wig16rgwIg4Bta//oBPsQ7g=
=e5Y4
-END PGP SIGNATURE-


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

Bug#309986: gcc-4.0 build problems on powerpc

2005-05-21 Thread Roger Leigh 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Falk Hueffner <[EMAIL PROTECTED]> writes:

> Roger Leigh <[EMAIL PROTECTED]> writes:
>
>> I found quite a number of errors, many minor, some serious, building
>> 4.0.0-7, in both the gcc build and while packaging.  I've put all
>> the detail in bug #309986.
>
> You mention warnings about "returning pointer to automatic variable"
> and "expr is called with too many arguments". I cannot find them in
> the script, can you point them out? The other warnings seem harmless.

Sorry the listing is so long: it took a few hours to edit the 11 MiB
to under 200 KiB.

It's on line 30075 of the full listing:

./libtool: line 4696: /usr/bin/expr: Argument list too long
using piecewise archive linking...

This is while creating libgcj.a, so there may be some object files
missed out of the ar command.  It's happening inside libtool.

/home/rleigh/gcc/gcc-4.0-4.0.0/src/libobjc/thr.c:117: warning: 'noreturn' 
function does return

Remove the noreturn attribute??

../../../src/boehm-gc/mark_rts.c: In function 'GC_approx_sp':
../../../src/boehm-gc/mark_rts.c:379: warning: function returns address of 
local variable

That's never a good idea.

And there's a shlibs problem in a few packages, for example

dh_shlibdeps -pgnat-4.0 -L libgnat-4.0 -l debian/libgnat-4.0/usr/lib
dpkg-shlibdeps: warning: could not find path for ld.so.1
dpkg-shlibdeps: warning: could not find any packages for  (ld.so.1)
dpkg-shlibdeps: warning: unable to find dependency information for shared 
library ld (soname 1, path , dependency field Depends)

$ cat /var/lib/dpkg/info/libc6.shlibs
ld 1 libc6 (>= 2.3.2.ds1-21)

Presumably, there's a binary linked incorrectly or a problem in the
rules or the control file causing this.  Maybe something's assuming
something i386-specific, like ld-linux.so.2, but I'm afraid I'm not at
all familiar with the GCC packaging.


Regards,
Roger

- -- 
Roger Leigh
Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
Debian GNU/Linuxhttp://www.debian.org/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iD8DBQFCjwmGVcFcaSW/uEgRAgY+AKDrA/JLbY3tzAjSEieOid6DmpvZtgCeLWH3
3mwuyFVMv6NxoWzYKsYAbIw=
=HsT1
-END PGP SIGNATURE-


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

Bug#309986: gcc-4.0 build problems on powerpc

2005-05-21 Thread Roger Leigh 
ind dependency information for shared 
library ld (soname 1, path , dependency field Depends)
dpkg-shlibdeps: warning: could not find any packages for  (ld.so.1)
dpkg-shlibdeps: warning: unable to find dependency information for shared 
library ld (soname 1, path , dependency field Depends)
dpkg-shlibdeps: warning: could not find any packages for  (ld.so.1)
dpkg-shlibdeps: warning: unable to find dependency information for shared 
library ld (soname 1, path , dependency field Depends)
dpkg-shlibdeps: warning: could not find any packages for  (ld.so.1)
dpkg-shlibdeps: warning: unable to find dependency information for shared 
library ld (soname 1, path , dependency field Depends)
Use of uninitialized value in scalar assignment at /usr/bin/dh_shlibdeps line 
138,  line 3.

Making things simpler:

[EMAIL PROTECTED]:~/gcc/gcc-4.0-4.0.0$ dpkg-shlibdeps -O 
-edebian/gnat-4.0/usr/bin/gnat
dpkg-shlibdeps: warning: could not find path for ld.so.1
dpkg-shlibdeps: warning: could not find any packages for  (ld.so.1)
dpkg-shlibdeps: warning: unable to find dependency information for shared 
library ld (soname 1, path , dependency field Depends)
shlibs:Depends=libc6 (>= 2.3.2.ds1-21)

[EMAIL PROTECTED]:~/gcc/gcc-4.0-4.0.0$ ldd debian/gnat-4.0/usr/bin/gnat 
libc.so.6 => /lib/libc.so.6 (0x0fe70000)
/lib/ld.so.1 => /lib/ld.so.1 (0x0ffd)

$ objdump -p debian/gnat-4.0/usr/bin/gnat | grep NEEDED
  NEEDED  libc.so.6
  NEEDED  ld.so.1


Regards,
Roger

-- 
Roger Leigh
Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
Debian GNU/Linuxhttp://www.debian.org/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.


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

Bug#317233: gcc-4.0 regression, possibly powerpc-specific, causes segfault in compiled binary

2005-07-06 Thread Roger Leigh 
Package: gcc-4.0
Version: 4.0.0-11
Severity: normal

If I compile schroot

http://ftp.debian.org/debian/pool/main/s/schroot/schroot_0.1.2-1.dsc
http://ftp.debian.org/debian/pool/main/s/schroot/schroot_0.1.2.orig.tar.gz
http://ftp.debian.org/debian/pool/main/s/schroot/schroot_0.1.2-1.diff.gz

with gcc-3.3 and gcc-3.4, the resulting binary works.  If I build with
gcc-4.0, it segfaults.  Try "schroot --help", for example.

The problem only because apparent when the gcc-defaults changed to
default to 4.0.

I've tried compiling with nearly every gcc warning enabled, but I
couldn't find anything other than trivial warnings.  I've also reviewed
the code, but can't see anything wrong.  The code is fairly simple;
I'm not using any GCC extensions, just plain C99 source.

The fault occurs shortly after startup, calling parse_options()
(schroot/schroot.c).

If it would be useful, I can reduce it to a smaller test case, but the
code worked just fine with 3.3.


Regards,
Roger

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (990, 'unstable')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)

Versions of packages gcc-4.0 depends on:
ii  binutils2.15-7   The GNU assembler, linker and bina
ii  cpp-4.0 4.0.0-11 The GNU C preprocessor
ii  gcc-4.0-base4.0.0-11 The GNU Compiler Collection (base 
ii  libc6   2.3.2.ds1-22 GNU C Library: Shared libraries an
ii  libgcc1 1:4.0.0-11   GCC support library

Versions of packages gcc-4.0 recommends:
ii  libc6-dev   2.3.2.ds1-22 GNU C Library: Development Librari
ii  libmudflap0-dev 4.0.0-11 GCC mudflap support libraries (dev

-- no debconf information


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

Bug#317233: gcc-4.0 regression, possibly powerpc-specific, causes segfault in compiled binary

2005-07-07 Thread Roger Leigh 
Matthias Klose <[EMAIL PROTECTED]> writes:

> Roger Leigh writes:
>> The fault occurs shortly after startup, calling parse_options()
>> (schroot/schroot.c).
>> 
>> If it would be useful, I can reduce it to a smaller test case, but the
>> code worked just fine with 3.3.
>
> yes, it would be useful. is this powerpc specific, or is seen on other
> archs as well?

I only have access to a powerpc sid system with the appropriate
build-deps, so I've only tested on powerpc.

I found the problem eventually.  It was fixed by the addition of a
single const.  I'm not sure why this was fatal:

@@ -61,7 +60,7 @@
   };

 /* Command-line options. */
-static GOptionEntry entries[] =
+static const GOptionEntry entries[] =
 {
   { "all", 'a', 0, G_OPTION_ARG_NONE, &opt.all, N_("Run command in all 
chroots"), NULL },
   { "chroot", 'c', 0, G_OPTION_ARG_STRING_ARRAY, &opt.chroots, N_("Use 
specified chroot"), "chroot" },


Before:
$ ./schroot --help
Usage:
  schroot [OPTION...] - run command or shell in a chroot

Segmentation fault


After:
$ ./schroot --help
Usage:
  schroot [OPTION...] - run command or shell in a chroot

Help Options:
  -?, --help Show help options

Application Options:
  -a, --all  Run command in all chroots
  -c, --chroot=chrootUse specified chroot
  -u, --user=userUsername (default current user)
  -l, --list List available chroots
  -i, --info Show information about chroot
  -p, --preserve-environment Preserve user environment
  -q, --quietShow less output
  -V, --version  Print version information


I'm not sure if this is a gcc bug or not.  It's certainly a little
odd, and not at all obvious.


Regards,
Roger

-- 
Roger Leigh
Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
Debian GNU/Linuxhttp://www.debian.org/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.


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

Bug#317233: gcc-4.0 regression, possibly powerpc-specific, causes segfault in compiled binary

2005-07-07 Thread Roger Leigh 
Matthias Klose <[EMAIL PROTECTED]> writes:

>> If it would be useful, I can reduce it to a smaller test case, but the
>> code worked just fine with 3.3.
>
> yes, it would be useful.

Attached, though it's more a test of success than failure.

This differs from the fix I mentioned in the previous mail, in that I
stripped everything out except for the option parsing, *but* I didn't
make the options const.  However, it works without me applying the
const fix.

Build with
gcc -o schroot schroot.c `pkg-config --cflags --libs gobject-2.0`


Regards,
Roger

-- 
Roger Leigh
Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
Debian GNU/Linuxhttp://www.debian.org/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.
/* schroot - securely enter a chroot
 *
 * Copyright © 2005  Roger Leigh <[EMAIL PROTECTED]>
 *
 * schroot 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 2 of the License, or
 * (at your option) any later version.
 *
 * schroot 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 this program; if not, write to the Free Software
 * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
 * MA  02111-1307  USA
 *
 */

#define _GNU_SOURCE
#include 
#include 
#include 

#include 

#include 

#include 
#include 

/* Stored command-line options. */
static struct {
  char **chroots;
  char **command;
  char *user;
  gboolean preserve;
  gboolean quiet;
  gboolean list;
  gboolean info;
  gboolean all;
  gboolean version;
} opt =
  {
.chroots = NULL,
.command = NULL,
.user = NULL,
.preserve = FALSE,
.quiet = FALSE,
.list = FALSE,
.info = FALSE,
.all = FALSE,
.version = FALSE
  };

/* Command-line options. */
static GOptionEntry entries[] =
{
  { "all", 'a', 0, G_OPTION_ARG_NONE, &opt.all, N_("Run command in all chroots"), NULL },
  { "chroot", 'c', 0, G_OPTION_ARG_STRING_ARRAY, &opt.chroots, N_("Use specified chroot"), "chroot" },
  { "user", 'u', 0, G_OPTION_ARG_STRING, &opt.user, N_("Username (default current user)"), "user" },
  { "list", 'l', 0, G_OPTION_ARG_NONE, &opt.list, N_("List available chroots"), NULL },
  { "info", 'i', 0, G_OPTION_ARG_NONE, &opt.info, N_("Show information about chroot"), NULL },
  { "preserve-environment", 'p', 0, G_OPTION_ARG_NONE, &opt.preserve, N_("Preserve user environment"), NULL },
  { "quiet", 'q', 0, G_OPTION_ARG_NONE, &opt.quiet, N_("Show less output"), NULL },
  { "version", 'V', 0, G_OPTION_ARG_NONE, &opt.version, N_("Print version information"), NULL },
  { G_OPTION_REMAINING, 0, 0, G_OPTION_ARG_STRING_ARRAY, &opt.command, NULL, NULL }
};

/**
 * parse_options:
 * @argc: the number of arguments
 * @argv: argument vector
 *
 * Parse command-line options.  The options are places in the opt
 * structure.
 */
static void
parse_options(int   argc,
	  char *argv[])
{
  GError *error = NULL;

  GOptionContext *context = g_option_context_new (_("- run command or shell in a chroot"));
  g_option_context_add_main_entries (context, entries, "schroot");
  g_option_context_parse (context, &argc, &argv, &error);
}

/**
 * print_version:
 * @file: the file to print to
 *
 * Print version information.
 */
void
print_version (FILE *file)
{
  g_fprintf(file, _("schroot (Debian sbuild) %s\n"), "gcc-debug");
  g_fprintf(file, _("Written by Roger Leigh\n\n"));
  g_fprintf(file, _("Copyright (C) 2004-2005 Roger Leigh\n"));
  g_fprintf(file, _("This is free software; see the source for copying conditions.  There is NO\n"
		"warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.\n"));
}

/**
 * debug_logfunc:
 * @log_domain: the log domain
 * @log_level: the logging level
 * @message: the message to log
 * @user_data: extra detail
 *
 * Log a debugging message.  This is a "NULL" message handler that
 * does nothing, discarding all messages.
 */
void debug_logfunc (const gchar *log_domain,
		GLogLevelFlags log_level,
		const gchar *message,
		gpointer user_data)
{
  /* Discard all messages. */
}

/**
 * main:
 * @argc: the number of arguments
 * @argv: argument ve

Bug#317233: gcc-4.0 regression, possibly powerpc-specific, causes segfault in compiled binary

2005-07-08 Thread Roger Leigh 
Matthias Klose <[EMAIL PROTECTED]> writes:

retitle 317233 gcc-4.0 regression causes segfault in compiled binary
thanks

> yes, it would be useful. is this powerpc specific, or is seen on other
> archs as well?

It's also been confirmed on i386 (all the previous info applies
equally to i386 as well as powerpc).  The cause is not apparent
however.

Because the test case works, _and_ adding const works, exactly what
changed is not at all clear.  The fault is in IA__g_str_hash(), called
from g_option_context_parse() in parse_options().  gdb shows that the
argc and argv passed to g_option_context_parse are not corrupted on
entry.  Matthijs Mohlmann reports random corruption of argc though
(but it varies from run to run).

>From #debian-bugs:

Active2: do you want a backtrace ?
rleigh:  Yes please (gdb is broken on ppc for me).  Could you next
 change 'static GOptionEntry entries[] =' to 'static const
 GOptionEntry entries[] =' in schroot/schroot.c, and try
 again?

Active2: can i paste here ?
rleigh:  Sure.
Active2: #0  0xb7f631e7 in g_str_hash () from /usr/lib/libglib-2.0.so.0
Active2: #1  0xb7f3d7a4 in g_hash_table_insert () from /usr/lib/libglib-2.0.so.0
Active2: #2  0xb7f5606d in g_option_context_add_main_entries ()
Active2: from /usr/lib/libglib-2.0.so.0
Active2: #3  0xb7f57af7 in g_option_context_parse () from 
/usr/lib/libglib-2.0.so.0

rleigh:  Thanks.  Could you try adding the const keyword, and try
 again?
Active2: now it is solved with the const keyword
rleigh:  Bizarre!  I can't see any reason why making it const should do
 that, since g_option_context_add_main_entries() takes a const
 pointer.  It shouldn't matter that the object isn't actually
 const.

rleigh:  Please could you try building the patch here:
 
http://bugs.debian.org/cgi-bin/bugreport.cgi/schroot.c?bug=317233&msg=12&att=1
rleigh:  Build with gcc -o schroot schroot.c `pkg-config --cflags --libs 
gobject-2.0`
rleigh:  This doesn't add the const, but strips out other bits.
Active2: works
rleigh:  Thanks.  So it's identical to powerpc.
Active2: np

rleigh:  Now for the hard question!  Any idea what's going on?
Active2: is glib already compiled with the new gcc ? i don't know if
 that can be a problem
rleigh:  Active2: not yet; it shouldn't be needed for C code.
rleigh:  I'll rebuild it to see.

Active2: sometimes it goes ok and sometimes it segfaults
Active2: #4  0x0804a4da in main (argc=1601463655, argv=0x5f746567) at 
schroot.c:93
Active2: config = Variable "config" is not available.
rleigh:  Is this with the const or without?
Active2: without
rleigh:  The original, or the testcase from the bug report?
Active2: The original

Active2: rleigh, is this ok:
Active2: (gdb) print argc
Active2: $2 = -1073742940
Active2: that's in parse_options
rleigh:  Active2: No; that's very broken.  I've seen that happen
 before, I just can't remember why.  Memory corruption is
 likely.

rleigh:  Active2: Could you try 'nm schroot/schroot | grep
 parse_options'?  For some reason the symbol is not visible.
Active2: [EMAIL PROTECTED] % nm /usr/bin/schroot| grep parse_options
~
Active2: [EMAIL PROTECTED] %

Active2: rleigh, can you try the following:
Active2: replace 'parse_options(argc, argv);' with
 'parse_options(&argc, argv);' in the main function
rleigh:  Active2: It segfaults in IA__g_str_hash().
rleigh:  (and also if I change parse_options to take an int *argc)
Active2: no segfault here, but what i don't understand is:

Active2: when i run schroot --help (with gdb) i get this:
Active2: Breakpoint 1, main (argc=2, argv=0x1) at schroot.c:201
Active2: is the argc right ?
Active2: I don't know how to fix that
rleigh:  Yes.  argv[] will be set to {"schroot", "--help", NULL};
 i.e. 2 options (argv[0] is typically the program name, and
 the options follow that).
Active2: rleigh, testing with a simple c program it works (argc gets
 the correct value in the function i pass argc to) so it must
 go fault earlier
Active2: sorry i'm out of options
rleigh:  Active2: I'm not sure.  breaking on g_option_context_parse
 shows argc == 2.



Regards.
Roger

-- 
Roger Leigh
Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
Debian GNU/Linuxhttp://www.debian.org/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.


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

Bug#317233: gcc-4.0 regression, possibly powerpc-specific, causes segfault in compiled binary

2005-07-09 Thread Roger Leigh 
reassign 317233 schroot
retitle 317233 command-line options are not terminated by a null option
thanks

This was due to an array of structs not having a null member.  Using
the const qualifier moved it to .rodata, where it worked by chance.

Sorry to bother you with this.


Roger

-- 
Roger Leigh
Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
Debian GNU/Linuxhttp://www.debian.org/
GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.


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

Using "typename std::iterator" causes segfault

2004-02-03 Thread Roger Leigh 

>Submitter-Id:  net
>Originator:    Roger Leigh
>Organization:  Debian Project
>Confidential:  no
>Synopsis:  Using "typedef typename std::iterator difference_type" causes a 
>segfault.
>Severity:  non-critical
>Priority:  low
>Category:  c++
>Class: ice-on-illegal-code
>Release:   3.3.3 20031229 (prerelease) (Debian) (Debian testing/unstable)
>Environment:
System: Linux wrynose 2.6.1 #3 Tue Jan 20 23:27:03 GMT 2004 i686 GNU/Linux
Architecture: i686


host: i486-pc-linux-gnu
build: i486-pc-linux-gnu
target: i486-pc-linux-gnu
configured with: ../src/configure -v 
--enable-languages=c,c++,java,f77,pascal,objc,ada,treelang --prefix=/usr 
--mandir=/usr/share/man --infodir=/usr/share/info 
--with-gxx-include-dir=/usr/include/c++/3.3 --enable-shared --with-system-zlib 
--enable-nls --without-included-gettext --enable-__cxa_atexit 
--enable-clocale=gnu --enable-debug --enable-java-gc=boehm 
--enable-java-awt=xlib --enable-objc-gc i486-linux
>Description:
$ g++ -o test test.cc
test.cc:24: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
>How-To-Repeat:
1   #include 
2   
3   template
4   class myclass
5   {
6   private:
7 T m_value;
8   public:
9 myclass(T& value): m_value(value) {}
   10   
   11 class myiter : public std::iterator
   12 {
   13 public:
   14   typedef std::size_t size_type;
   15   typedef typename std::iterator difference_type;
   16   
   17 private:
   18   size_type m_pos;
   19   
   20   myiter(size_type pos): m_pos(pos) {}
   21   
   22 public:
   23   myiter operator + (difference_type incr)
   24   {
   25 size_type pos = m_pos;
   26 if (pos + incr < m_result->size())
   27   pos += incr;
   28 else
   29   pos = m_result->size();
   30 return myiter(*m_result, pos);
   31   }
   32 };
   33   };
   34   
   35   int main()
   36   {
   37 myclass i;
   38 return 0;
   39   }
>Fix:
None, sorry.