It's probably binutils. Expect another upload (of 15-1) in the next
24hrs.
C
On Thu, 1 Aug 2002, Jack Howarth wrote:
> What happened to the gcc 3.1.1 build on debian ppc sid? It looks
> horribly broken from the log. I ask because I built locally a
> gcc 3.1.1 package using the previous pre
YAEGASHI Takeshi wrote:
> > Is sh a new or a revived port? Is there a reason not go with
> > gcc-3.1/gcc-3.2?
> >
> > No Fortran, no Java?
>
> Sorry I'm not certain about the current status of GNU toolchain. Does
> the ABI change between GCC 3.0 and 3.1 or later?
[...]
> So, it might be
What happened to the gcc 3.1.1 build on debian ppc sid? It looks
horribly broken from the log. I ask because I built locally a
gcc 3.1.1 package using the previous pre3 debian packaging patches
and rules and the gcc 3.1.1 official release tarballs. It built
fine and passes all of the test suite
Hi,
At Wed, 31 Jul 2002 21:11:16 +0200,
Matthias Klose wrote:
>
> YAEGASHI Takeshi writes:
> > Package: gcc-defaults
> > Version: 1.0
> > Severity: wishlist
> > Tags: patch
> >
> > Hi,
> >
> > I'm one of the porters of Debian/sh.
Please visit http://debian.dodes.org/sh for Debian/sh porting st
On Thu, 2002-08-01 at 08:11, Phil Edwards wrote:
> On Wed, Jul 31, 2002 at 10:45:49PM -0700, Norbert Kiesel wrote:
> > stlport (which is a
> > replacement/extension of libstdc++)
>
> Other way around, actually, and even that's not entirely accurate.
Yeah, didn't want to go too deep here (I actual
Dawid Jarosz <[EMAIL PROTECTED]> writes:
> I'm wodering why this code doesn't work. It looks like when the program
> is about to throw exception i cashes with SIGABR signal.
I can't reproduce this. What architecture, what gcc package, what
compiler flags?
Regards,
Martin
Many free java VMs are built on the classpath libraries. GCJ has its own
version of these libraries for its java-to-native compiler. Many users
would expect to use both of these without conflicts. PLease don't
'conflicts' classpath and libgcj3; a better solution would be to put
gcj's /usr/lib/se
On Wed, Jul 31, 2002 at 10:45:49PM -0700, Norbert Kiesel wrote:
> stlport (which is a
> replacement/extension of libstdc++)
Other way around, actually, and even that's not entirely accurate.
> detects the path during configuration,
> but then stores it somewhere in its own headers.
How odd.
Ph
I'm wodering why this code doesn't work. It looks like when the program
is about to throw exception i cashes with SIGABR signal.
int main () {
try {
throw 1;
} catch (...) {
}
return 1;
}
Is it a bug in a g++-3.1 package?
--
+- Dawid Jarosz ---
Hi,
I'm perfectly fine with the new path (though it would have been nice to mention
it
in the changelog).
I think I was not exact enough when stating my problem: stlport (which is a
replacement/extension of libstdc++) detects the path during configuration,
but then stores it somewhere in its
10 matches
Mail list logo
