tal; urgency=medium
+
+ * Non-maintainer upload.
+ * Rename libraries for 64-bit time_t transition.
+
+ -- Steve Langasek Wed, 31 Jan 2024 19:27:02 +
+
libabigail (2.4-2) unstable; urgency=medium
* Update from the 2.4 branch:
diff -Nru libabigail-2.4/debian/control libabigail-2.4/debian/con
fixes the fact that gcc-python-plugin was not
previously using the cflags from dpkg-buildflags for the build, which seems
kind of important!
I've uploaded this patch to Ubuntu. Please consider including it in Debian
as well.
Thanks,
--
Steve Langasek Give me a lever lo
patch
2020-02-20 21:44:49.0 -0800
@@ -0,0 +1,40 @@
+Description: fix compatibility with Python 3.8
+ Python 3.8 changes the type of an element of the PyTypeObject struct
+ (https://www.python.org/dev/peps/pep-0590/) leading to compiler errors.
+Author: Steve Langasek
+Last-Update: 20
s shouldn't be done
> before the jessie release.
However, bumping the CPU requirements for the armel port to armv7 also make
that port completely redundant; at that point it's just a slow armhf with no
advantages.
--
Steve Langasek Give me a lever long enough and a Free O
xtract the triplet with regex from the library path (which is somewhat
> error prone).
I know it's part of the patch that Matthias is in the process of discussing
with upstream. So yes, I think it's "being upstreamed" though that doesn't
mean it's been accepted
On Wed, Jun 29, 2011 at 01:10:35PM +0200, Ondřej Surý wrote:
> the build of src:db on powerpc failed[1] because:
> On Wed, Jun 29, 2011 at 01:25, Steve Langasek wrote:
> > It's a (multiarch) bug in gcc-defaults; /usr/lib/libgcj_bc.so.1 in the
> > libgcj-bc metapac
> Is this only an issue with cpp, or with gcc too (holding headers and .o
> files) too?
I haven't yet encountered any cases where this matters for gcc, so I would
recommend only changing cpp for now.
Thanks,
--
Steve Langasek Give me a lever long enough and a Free O
If you see flaws in my reasoning, please make cpp Multi-Arch: allowed
instead, and let me know what my error is. :)
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Develope
Hi Matthias,
On Wed, Jun 01, 2011 at 12:03:36AM +0200, Matthias Klose wrote:
> >Some time ago I asked Steve Langasek to verify what output of:
> >
> >$ gcc -v /dev/null |& grep ^LIBRARY_PATH
> >
> >will return on the multiarch system. Basically, cmake pa
e for implementation and the interface packages should use to query these
paths.
Cc:ing the respective maintainer mailing lists for sign-off.
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the
u natty as far as multiarch
support is concerned.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@
Package: ftp.debian.org
Severity: normal
I chanced to notice that the gcc-4.1-doc-non-dfsg and gcc-4.2-doc-non-dfsg
source packages are still present in unstable. gcc-4.2 hasn't been included
in Debian since lenny, and gcc-4.1 has been removed from unstable
post-squeeze. The documentation ought
On Thu, Mar 17, 2011 at 01:12:27AM -0700, Steve Langasek wrote:
> Attached is a backport to gcc-4.4 of all my multiarch changes to date for
> gcc-4.5.
Here is a further set of changes to be applied on top of the previous patch.
The previous upload of multiarch gcc-4.4 to Ubuntu showed a
ber for this needs to be bumped once this is
+officially in the archive.)
+
+ -- Steve Langasek Tue, 08 Mar 2011 23:40:12 -0800
+
gcc-4.5 (4.5.2-5) unstable; urgency=low
* Update to SVN 20110305 (r170696) from the gcc-4_5-branch.
=== modified file 'debian/control.m4'
--- debian/
On Thu, Feb 17, 2011 at 06:36:08PM -0800, Steve Langasek wrote:
> I have another round of multiarch fixes for gcc, following on to the ones
> from last July. They're fairly minor; I think the changelog speaks for
> itself:
Funny thing, it turns out that gcj is much farther down
hould be the default in Debian soon.
Is that the case, or should I prepare gcc-4.4 patches as well?
Please cc: me on replies as I'm not subscribed to debian-gcc.
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set
oving libglitz is more painful than it would be otherwise,
because instead of just rebuilding cairo itself without glitz, you must
rebuild everything above cairo in the stack that used pkg-config for
linking.
I don't argue that this makes --as-needed *correct* as a default
.1) unstable; urgency=low
+
+ * debian/rules.d/binary-gcc.mk: make sure the libgcc_s.so symlink is
+moved to the gcc lib dir before trying to put it in a package, otherwise
+it goes missing on powerpc.
+
+ -- Steve Langasek Sat, 04 Sep 2010 05:50:38 +
+
gcc-4.4 (4.4.4-12) unstable; urgency
this
submitted for inclusion in the Debian package.
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
s
On Thu, Jul 29, 2010 at 10:01:32AM +0200, Marcin Juszkiewicz wrote:
> Dnia czwartek, 29 lipca 2010 o 02:13:24 Steve Langasek napisał(a):
> > Trying to get ready for the next stage of multiarch deployment, I ran into
> > a couple of problems with the packaging of multiarch sup
d.
Please cc: me on replies as I'm not subscribed to debian-gcc.
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhtt
In the OpenSSL case, we had definite information that the license conflict
would not be resolved. If it came to light that this recent license
conflict was deliberate on the part of the FSF, I would certainly support
handling it in a consistent manner.
Cheers,
--
Steve Langasek Gi
also not on the line personally for any
legal liability on Canonical's side and as a result this may not be very
persuasive, but it's my firm belief that this is the right standard for the
Debian ftpmasters to use as well.)
Cheers,
--
Steve Langasek Give me a lever long e
ed to be added to the
package in the next upload, per the recent announcement regarding lintian
enforcement at archive accept time.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Deve
ng.
It's still my opinion that if this gcc-4.3 is not going to be
backwards-compatible with existing kernels for lenny, we're better off not
making gcc-4.3 the default compiler on the affected archs.
--
Steve Langasek Give me a lever long enough and a Free OS
Debia
fails to build under g++-4.3, though.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL
On Mon, Dec 31, 2007 at 02:44:00PM +0100, Martin Michlmayr wrote:
> * Steve Langasek <[EMAIL PROTECTED]> [2007-12-29 11:08]:
> > > > nmv-sess-mgr.cc: In member function 'virtual void
> > > > nemiver::SessMgr::store_session(nemiver::ISessMgr::Session&a
ss-mgr.cc:343: internal compiler error: Segmentation fault
> Works fine here. I think the package should be retried on ARM.
Yes, reasonable since the failing buildd was elara; but then, it would still
be good to know why gcc-4.2 is segfaulting on netwinder si
tags 438066 -moreinfo
tags 438436 moreinfo
thanks
On Sun, Sep 16, 2007 at 04:59:29PM +0200, Matthias Klose wrote:
> tag 438066 + moreinfo
> thanks
> please recheck with 4.2 and 4.3/snapshot
Forwarding to the right bug.
--
Steve Langasek Give me a lever long enough a
was asked to report back results with a recent gcc-snapshot; did I
> miss an answer?
http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=123;bug=428582
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
the fact that xulrunner has been out-of-date on
mips* for over a month now due to build failures that look like they are
probably a gcc bug, thereby preventing security fixes (and updates to 27
other significant packages) from reaching testing.
--
Steve Langasek Give me a lev
; Did someone check already ?
Probably not; this discussion doesn't seem to be cc:ed to debian-mips?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED]
ppa, ia64, powerpc, s390, or
sparc.
arm built the most recent version of xulrunner with gcc-4.1 4.1.2-8, so it's
unknown whether it's affected.
m68k fails when building with gcc-4.1 4.1.2-12 with the error you listed
above.
--
Steve Langasek Give me a
her gcj-4.1 and
classpath need to be fixed to work with the new xulrunner, or xulrunner's
bugs need to be fixed without coupling them to a behavior change that breaks
the other packages.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
y the new xulrunner,
AFAICS. Even if the "bug" belongs to gcj-4.1, this change in xulrunner's
behavior is grounds for not letting the new xulrunner into etch. Security
updates need to not break related packages.
--
Steve Langasek Give me a lever long enough and a
'Conflicts+Replaces' more correct in this case? Why?
The 'Replaces' affects how the packaging tools decide which package should
take precedence in the case of a conflict.
> I'm ready to upload version with 'Conflicts+Replaces' at any moment if
h.
> This upload fixes RC bug (#403328); the only change from previous version
> is addition of missing Conflicts: entry.
I don't understand why this is listed as a Conflicts:, instead of as a
Conflicts: + Replaces:. Matthias, could you please comment?
--
Steve Langasek
#x27;s
> broken gij, but otherwise things look OK. I would recommend we include
> this patch. I'm not sure there's any point submitting it upstream
> until the ARM libffi bits go; not sure what status on that is.
Beautiful! I'll happily grant a freeze exception
d?
> the upstream tarball has the same code, just some more GFDL'ed files
> removed. changes from upstream svn are included as a diff.
Ok, thanks for the clarification. gcj-4.1 4.1.1-17 is unblocked, in
anticipation of the arm upload.
Cheers,
--
Steve Langasek Give me
On Thu, Nov 02, 2006 at 01:23:17PM +0100, Matthias Klose wrote:
> Steve Langasek writes:
> > On Mon, Oct 23, 2006 at 01:18:35AM +0200, Matthias Klose wrote:
> > > Please consider moving the following packages to testing:
> > > gcj-4.1
> > I'm wondering whe
On Thu, Nov 02, 2006 at 01:11:24PM +0100, Matthias Klose wrote:
> Steve Langasek writes:
> > so in the absence of any movement in this area, I still need to
> > know what Debian is going to do with gcj on ARM for the upcoming etch
> > release.
> in the worst case, remove
I would love to see that happen, but I'm not an ARM porter and don't have
access to an appropriate ARM development environment that would let me work
on this; so in the absence of any movement in this area, I still need to
know what Debian is going to do with gcj on ARM for the u
keeping this updated version
of gcj-4.1 from being hinted into testing, though that seems to have been an
OOD error on the buildd; given back now.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the
it's ready (which seems to first require manual removal of libssp0
from unstable for those archs where you've dropped it).
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the
that mean the bug should be closed as a non-issue? The grep command
isn't sufficient to tell that there are any invariant sections or cover
texts here.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on,
gt; with "prctl --unaligned=default". ecj-bootstrap did build on the
> buildd.
This means the version of gcj-4.1 is still RC-buggy and will presumably
require a freeze exception for etch; documenting this in the BTS.
--
Steve Langasek Give me a lever long enough an
and much chance of being included in the etch release without rapid
improvement.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www
ve.
So for the current 2.6.17 it's still needed for *all* architectures, or
could gcc-4.0 still be dropped on some architectures where the kernel is
already using gcc-4.1?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set
didate for
binary cleanup. Please remove these packages from debian/control when
they're no longer being built.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[
1-free; it may be
a bug in libgcc4 instead, but I think that's yet to be determined. In the
meantime, I think it's best to reassign this back to qt-x11-free.
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
On Sat, Aug 19, 2006 at 02:39:15PM +0200, Matthias Klose wrote:
> Steve Langasek writes:
> > On Sat, Aug 19, 2006 at 11:42:03AM +0200, Robert Millan wrote:
> > > It's a little weird. The package that puts the plugin into firefox dir
> > > (via
> > >
ect. I suppose when a few versions of gcjwebplugin-X.Y exist,
> java-gcj-compat-plugin will decide which one is more suitable by changing the
> dependency and the symlink.
That sounds like a terrible amount of complexity to me. I can't imagine why
it would ever be beneficial to carry mo
;ll have no browser java
> support
> otherwise.
Is gcjwebplugin in a presentable state yet? Last I knew, it still had
serious security problems. (BTW, why does the plugin package need to have
the upstream version number in its name?)
--
Steve Langasek Give me a lever lo
e first branch of an ORed dependency, so this is a
serious bug.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
--
To
Now that g++ points to g++-4.1 on hppa, is the correct fix here to drop
g++-4.0 and g++-3.4 packages on this architecture?
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL
On Sun, Jun 04, 2006 at 04:47:31PM +0200, Matthias Klose wrote:
> Falk Hueffner writes:
> > Steve Langasek <[EMAIL PROTECTED]> writes:
> > > Hi Matthias,
> > >> works for me.
> > > Have you tried building it with prctl --unaligned=signal? This is no
uploaded, which doesn't help us when we need a security upload
sometime...
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://w
On Wed, May 31, 2006 at 08:39:19AM +0200, Falk Hueffner wrote:
> Steve Langasek <[EMAIL PROTECTED]> writes:
> > retitle 369642 g++-4.0/alpha: -fvisibility-inlines-hidden segfaults on
> > reference to static method
> > thanks
> > Minimal test case attached, bug
is to break out
the definition of the cleanup() method so that it doesn't get inlined.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED]
ase candidate. I see
12 buildds actively uploading packages for m68k, is this too few or is there
some other problem?
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
bstdc++ is from gcc-4.1, resulting
in the double libgcc_s problem.
So "removing gcc-4.1 from his build system" isn't an option unless we find a
way to do this systemically for Debian.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
the libstdc++6 dependent packages with binary NMU's?
I guess having gcc-4.0 link against libgcc4 is out of the question?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED]
On Thu, Apr 13, 2006 at 11:20:38PM +0200, Frans Pop wrote:
> On Thursday 13 April 2006 22:59, Steve Langasek wrote:
> > I think etch should support 2.4 in the sense of "upgrade support only";
> > i.e., it should support 2.4 because we need to be able to install etch
>
ide support for 2.4
in etch.
This AFAIK will satisfy Joey's need for interim 2.4 compatibility, while
making it clear that the upgrade to 2.6 needs to happen before the etch+1
release.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer
the archive.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Apr 07, 2006 at 05:23:24PM -0400, Carlos Moffat wrote:
> On Fri, 2006-04-07 at 13:50 -0700, Steve Langasek wrote:
> > On Fri, Apr 07, 2006 at 10:16:17AM -0400, Carlos Moffat wrote:
> > > I'm seeing the same behavior, alt
; File "/usr/bin/apt-listchanges", line 30, in ?
> import apt_pkg
> ImportError: libstdc++.so.6: cannot handle TLS data
> but if I run 'sudo apt-listchanges' it works! Same for all other
> affected programs.
Do you have LD_PRELOAD or LD_LIBRARY_PATH variable
t also attached.
> Aurelian Jarno pointed out the following: only reproducible with 2.4
> kernels or if you (re)move /lib/tls on a 2.6 kernel.
> Officially we don't support 2.4 kernels anymore, whatever "deprecated"
> means.
> See http://lists.debian.org/debian-devel-anno
it's even documented here:
> http://gcc.gnu.org/onlinedocs/gcc-4.0.3/gcc/Target-Options.html) ?
I have no idea; I'm just not surprised that the various bits of the compiler
aren't truly interchangeable.
Cheers,
--
Steve Langasek Give me a lever long
Please don't drop the BTS from the recipient list when replying.
On Wed, Mar 22, 2006 at 04:27:46AM +0100, Christian E. Boehme wrote:
> On Tue, Mar 21, 2006 at 05:49:43PM -0800, Steve Langasek wrote:
> > Then you're obviously doing something wrong, but you haven't a
On Tue, Mar 21, 2006 at 10:23:40PM +0100, Christian E. Boehme wrote:
> On Mon, Mar 20, 2006 at 08:36:05PM -0800, Steve Langasek wrote:
> > Huh? Are you really suggesting that the standard C++ compiler has been
> > unable to find any of its own header files for over a week in unsta
g doesn't qualify as "rendering the package unusable".
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
g" the work. I think this is the right
point to stop at on glibc right now -- we really need to have support for
multiarch in dpkg an apt before usefully proceeding further.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to
putting files in /usr/lib/i486-linux-gnu/ may be
premature. Has thought been given to what this means for the upgrade path
when (...if) dpkg is extended to support installing Arch: i386 multiarch
debs directly on amd64? I suppose it should just be a Replaces:, but it
still seems like it will be an extra unnecessary transition.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
On Mon, Feb 20, 2006 at 11:10:41AM -0700, Bdale Garbee wrote:
> On Mon, 2006-02-20 at 02:23 -0800, Steve Langasek wrote:
> > If there's
> > consensus that putting this stuff in /usr/lib32 on amd64 is prettier than
> > /emul/ia32-linux, I see no reason not to move forwar
hough, it would be really really nice if multiarch happened, so
that making a lib multiarch-safe only required adjusting the paths the
package installs to, consistently across *all* architectures, and no more
fiddling with package names and doing double-builds on each architecture
nation between
maintainers.
> http://lists.debian.org/debian-devel-announce/2005/11/msg00022.html
Affects > 500 packages.
> For instance, there was no mention in the release team plans for etch:
Because it only affects a handful of packages that are using a non-default
compiler, which
hown in the bug log, or do we
need to consider dropping hppa from the list of etch release archs at this
point?
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[
t we would also have to reconsider
hppa's status as a release port, so hopefully someone will have a chance to
look at this soon.
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the wor
is
not caused by an RC bug in another package, that's a serious bug in the
package in question.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED]
you maybe summarize what the actual bug is and why it's
> libgcc2's fault? The BTS trail is pretty convoluted.
Yes, sorry. Let me quote Aurelien's last mail to 341675, which really
should have been sent to 342545:
On Sun, Dec 18, 2005 at 06:56:34PM +0100, Aurelien Jarno wro
gcc-4.0 will implement the ABI change. So I think the only option now is to
go for 1.33.1 in testing.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED]
> I believe that this bug has been fixed in or before gcc-4.0_4.0.2-3.
Based on what? Have you retested the jigdo build yourself? If so, the
jigdo maintainer should be notified, so that the build-dependency on gcc-3.4
can be reverted.
--
Steve Langasek Give me a lever l
name for all libraries affected.
What do you propose as the new name for these library packages?
(Apparently, these will then be the *real* "c2" libraries... but also
incompatible with those already shipped by other Debian-derived distros
under that name, such as Ubuntu...) Do we have any
On Sun, Oct 23, 2005 at 12:41:18PM -0700, Thomas Bushnell BSG wrote:
> Steve Langasek <[EMAIL PROTECTED]> writes:
> > If the gcc maintainers think that pointing g++ at g++-3.4 on these archs is
> > the best option, I'm game. One disadvantage is that it wouldn't let
On Sat, Oct 22, 2005 at 11:18:00PM -0700, Thomas Bushnell BSG wrote:
> Steve Langasek <[EMAIL PROTECTED]> writes:
> > This is the single most common build failure on arm, hppa, and m68k right
> > now, and has affected literally dozens or hundreds of other packages. I
&g
severity 335286 important
merge 335286 323133
thanks
On Sat, Oct 22, 2005 at 09:59:30PM -0700, Thomas Bushnell BSG wrote:
> Steve Langasek <[EMAIL PROTECTED]> writes:
> > reassign 335286 lilypond
> > thanks
> > On Sat, Oct 22, 2005 at 08:49:17PM -0700, Thomas Bushnell
hppa, and m68k, as g++-3.4
doesn't suffer from this particular bug.
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
[EMAIL PROTECTED] http://w
gt; download libgcj6-dev from ftp.debian.org, and I can't see such
> identifiers in this file.
Then I'm afraid you've downloaded the wrong version of the package, because
the current 3:4.0.2-2 version of libgcj6-dev for arm has
class ObjectInputStream$GetField;
on
for (i=0; i<4; i++)
{
help_items[i].accelerator = NULL;
help_items[i].callback = menu_show_game_doc;
help_items[i].item_type = "";
}
Yeah, this smashes the stack. Just because it worked with gcc-3.3 doesn't
mean t
n
unstable?
What is the last version of the compiler that you are able to use to
successfully compile this code in this environment with no other changes?
Have you confirmed that this bug exists in gcc-snapshot?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Develop
cessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see .
make[2]: *** [video.lo] Error 1
This is a regression relative to g++-3.3_1:3.3.6-6, and appears to be
reported upstream as PR 21041.
Cheers,
--
Ste
]>
gmp
Andreas Rottmann <[EMAIL PROTECTED]>
python-crypto
Guus Sliepen <[EMAIL PROTECTED]>
dhis-client
Matthias Urlichs <[EMAIL PROTECTED]>
gnutls12
Thanks,
--
Steve Langasek Give me a lever long enough and a
On Wed, Aug 31, 2005 at 12:09:40AM +0200, Bastian Blank wrote:
> On Tue, Aug 30, 2005 at 12:34:01AM -0700, Steve Langasek wrote:
> > When passing pointers to 4-byte types to memcpy(), gcc-4.0 generates
> > wrong code which assumes that these pointers are aligned at 4-byte
>
On Tue, Aug 30, 2005 at 02:08:17PM +0200, Falk Hueffner wrote:
> Steve Langasek <[EMAIL PROTECTED]>, [EMAIL PROTECTED] schrieb am 30.08.05
> 09:49:30:
> > When passing pointers to 4-byte types to memcpy(), gcc-4.0 generates
> > wrong code which assumes that these pointe
test case. The test case is derived from the failing code in
dhcp3 (bug #321987, #325605).
[EMAIL PROTECTED]:~$ gcc-4.0 -g -o memcpytest ./memcpytest.c && ./memcpytest
Bus error
[EMAIL PROTECTED]:~$ gcc-4.0 -DEXPLICIT_CAST -g -o memcpytest ./memcpytest.c &&
./memcpytest
[EMAIL PROTEC
found 322565 4.0.1-3
notfound 322565 4.0.1-4
thanks
The bug in question manifested with gcc-4.0 4.0.1-3; the 4.0.1-4 version has
been built for arm, but not yet uploaded, so it's not currently known if
this particular ICE is addressed.
--
Steve Langasek Give me a lever
Package: gcc
Version: 4:4.0.0-2
Severity: normal
The /usr/share/doc/gcc/README.Debian.gz file says:
Debian 3.2 (etch) is (mostly) built using the GCC 4.0.x compiler
collection.
It is not correct to assume that etch will be Debian 3.2. Please fix
this premature use of a version number. :)
-
On Thu, Jul 21, 2005 at 04:29:50PM +0200, Matthias Klose wrote:
> Steve Langasek writes:
> > Package: g++-4.0
> > Version: 4.0.1-2
> > Severity: important
> > jigdo is failing to build with g++-4.0 on m68k with the following error:
> > The unstable chroot on c
Package: g++-4.0
Version: 4.0.1-2
Severity: important
jigdo is failing to build with g++-4.0 on m68k with the following error:
g++ $cxx -c util/rsyncsum.cc -o util/rsyncsum.o
/usr/lib/gcc/m68k-linux-gnu/4.0.1/../../../../include/c++/4.0.1/bits/stl_bvector.h:
In member function 'std::_Bit_type*
1 - 100 of 115 matches
Mail list logo
