Package: libgcj2-dev
Version: 1:3.0-1
Severity: grave
dpkg: dependency problems prevent configuration of libgcj2-dev:
libgcj2-dev depends on libgcc0 (>= 1:3.0-0pre010613); however:
Package libgcc0 is not installed.
dpkg: error processing libgcj2-dev (--configure):
dependency problems - leaving
On Sun, Jun 24, 2001 at 12:00:36AM +0200, Matthias Klose wrote:
> Ok to enable -fuse-cxa-atexit as default? According to Laurents
> citations this should be safe for Linux glibc. Safe for the Hurd as
> well?
Should be. Might want to run it through a testsuite just to be sure,
of course.
--
Dani
Daniel Jacobowitz writes:
> On Sat, Jun 23, 2001 at 02:47:51PM +0200, Matthias Klose wrote:
> > Chris, any support in ld needed?
> >
> > laurent bonnaud writes:
> > > Package: g++-3.0
> > > Version: 1:3.0-1
> > > Severity: normal
> > >
> > >
> > > Hi,
> > >
> > > according t
On Sat, Jun 23, 2001 at 08:23:17PM +0100, Philip Blundell wrote:
> >I sincerely doubt that this will ever get past the Release Manager
> >unless you have a very good, very specific reason. I recommend talking
> >to him before spending your time.
>
> I think it's worth making the packages even if
There are disparities between your recently installed upload and the
override file for the following file(s):
chill_2.95.4-2_i386.deb: priority is overridden from optional to extra.
Either the package or the override file is incorrect. If you think
the override is correct and the package wrong p
>Submitter-Id: net-debian
>Originator:Jeff Bailey
>Organization:
>Confidential: no
>Synopsis: gcc-3.0 doesn't build shared C++ library on i386-pc-gnu
>Severity: serious
>Priority: medium
>Category: c++
>Class: sw-bug
>Release: 3.0 20010426 (Debian prere
>I sincerely doubt that this will ever get past the Release Manager
>unless you have a very good, very specific reason. I recommend talking
>to him before spending your time.
I think it's worth making the packages even if the Release Manager (who is
that for potato these days, anyway?) won't acc
Installing:
gcc-defaults_0.9.dsc
to pool/main/g/gcc-defaults/gcc-defaults_0.9.dsc
gcc-defaults_0.9.tar.gz
to pool/main/g/gcc-defaults/gcc-defaults_0.9.tar.gz
gcc_2.95.4-2_i386.deb
to pool/main/g/gcc-defaults/gcc_2.95.4-2_i386.deb
gobjc_2.95.4-2_i386.deb
to pool/main/g/gcc-defaults/gobjc_2.
On Sat, Jun 23, 2001 at 02:47:51PM +0200, Matthias Klose wrote:
> Chris, any support in ld needed?
>
> laurent bonnaud writes:
> > Package: g++-3.0
> > Version: 1:3.0-1
> > Severity: normal
> >
> >
> > Hi,
> >
> > according to http://gcc.gnu.org/bugs.html#known, it would seem to be a go
On Sat, Jun 23, 2001 at 01:19:39PM +0100, Philip Blundell wrote:
> I think our current "gcc 2.95.4" is stable enough, and sufficiently better
> than the 2.95.2 in potato, that we should consider making new packages to go
> into 2.2r4 or whatever the next version is going to be. I guess this shou
>the current 2.95.4 doesn't builf on s390, but 2.95.3, so it might be
>necessary to add a reverse-diff (for woody as well).
Is there any bug open for this? I couldn't find one from a quick look at the
lists for gcc and gcc-2.95. In any case I don't think we have to worry about
it for potato --
Chris, any support in ld needed?
laurent bonnaud writes:
> Package: g++-3.0
> Version: 1:3.0-1
> Severity: normal
>
>
> Hi,
>
> according to http://gcc.gnu.org/bugs.html#known, it would seem to be a good
> idea to compile g++-3.0 with the --use-cxa-atexit switch:
>
> >Global destruc
Philip Blundell writes:
> I think our current "gcc 2.95.4" is stable enough, and sufficiently better
> than the 2.95.2 in potato, that we should consider making new packages to go
> into 2.2r4 or whatever the next version is going to be. I guess this should
> be straightforward enough to achiev
I think our current "gcc 2.95.4" is stable enough, and sufficiently better
than the 2.95.2 in potato, that we should consider making new packages to go
into 2.2r4 or whatever the next version is going to be. I guess this should
be straightforward enough to achieve.
Anybody object to this? If
(re ajt's comments to bug #101878)
gcc-defaults doesn't build packages with epochs by default, so if we can
keep it that way we'll be more consistent with the other architectures.
But I think we just want to get something into the archive that works,
so whatever we can agree to .
cc'ing the m
15 matches
Mail list logo
