In case anyone is interested, I finally pinned down why the
GL server extension, libGLcore.a, from the XFree86 4.2.0-0pre1v1
package built under gcc 3.1.1 doesn't load properly. It appears
that when building under gcc 3.1.1, we become like alpha on ppc
and can no longer do a 'strip --strip-debug
On Mon, Jul 29, 2002 at 10:32:03PM -0400, Jack Howarth wrote:
> Daniel,
>What about the libgcc_s.so.1? I assume we are assured of compatibility
> in using a libgcc_s.so.1 from gcc 3.2 with binaries built with gcc 3.1.1
> then?
Yes.
--
Daniel Jacobowitz Carnegie Mell
Daniel,
What about the libgcc_s.so.1? I assume we are assured of compatibility
in using a libgcc_s.so.1 from gcc 3.2 with binaries built with gcc 3.1.1
then?
Jack
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL
On Mon, Jul 29, 2002 at 08:45:30PM -0400, Jack Howarth wrote:
> Daniel,
>Well if gcc 3.1.1 instantly disappears the moment gcc 3.2 hits the pool,
> won't that force openoffice/stl to deinstall on a dist-upgrade? It would
> nicer if we allows folks a grace period for their apps to get rebuilt
>
On Tue, Jul 30, 2002 at 01:33:34AM +0200, Marek Habersack wrote:
> On Tue, Jul 30, 2002 at 01:21:48AM +0200, Martin v. Loewis scribbled:
> > Marek Habersack <[EMAIL PROTECTED]> writes:
> >
> > > OK, I found the statement about the preceeding non-witespace tokens but,
> > > still, I would think tha
Daniel,
Well if gcc 3.1.1 instantly disappears the moment gcc 3.2 hits the pool,
won't that force openoffice/stl to deinstall on a dist-upgrade? It would
nicer if we allows folks a grace period for their apps to get rebuilt
before yanking the supporting libs they need.
On Mon, Jul 29, 2002 at 08:29:25PM -0400, Jack Howarth wrote:
> I noticed that the new gcc-3.1_3.1.1ds3-1 changelog notes that
> gcc 3.1.1 will go away when 3.2 arrives. Do we plan on having a period
> of time (say a month) where both 3.1.1 and 3.2 will co-exist in the
> sid pool? That might b
I noticed that the new gcc-3.1_3.1.1ds3-1 changelog notes that
gcc 3.1.1 will go away when 3.2 arrives. Do we plan on having a period
of time (say a month) where both 3.1.1 and 3.2 will co-exist in the
sid pool? That might be a good idea to allow folks to recompile any
packages that they might
On Mon, Jul 29, 2002 at 08:15:48PM +0200, Matthias Klose wrote:
>Brendan O'Dea writes:
>> More info: this error does not occur when building without -Duse64bitint.
>
>please could you recheck with gcc-3.1 please?
It would appear that 3.1 is OK. Nicholas Clark responded to a message
of mine on the
On Tue, Jul 30, 2002 at 01:21:48AM +0200, Martin v. Loewis scribbled:
> Marek Habersack <[EMAIL PROTECTED]> writes:
>
> > OK, I found the statement about the preceeding non-witespace tokens but,
> > still, I would think that something that breaks the kernel compile should be
> > important no matte
Marek Habersack <[EMAIL PROTECTED]> writes:
> OK, I found the statement about the preceeding non-witespace tokens but,
> still, I would think that something that breaks the kernel compile should be
> important no matter how trivial to work-around it is...
The question is whether it should be fixe
On Tue, Jul 30, 2002 at 12:35:07AM +0200, Martin v. Loewis scribbled:
> [EMAIL PROTECTED] writes:
>
> > printf(KERN_ERR "[" DRM_NAME ":%s] *ERROR* " fmt , __FUNCTION__, ##
> > args)
> [...]
> > which is invalid C syntax. ##' gets rid of the comma, so we get the
> > following instead:
> >
[EMAIL PROTECTED] writes:
> printf(KERN_ERR "[" DRM_NAME ":%s] *ERROR* " fmt , __FUNCTION__, ##
> args)
[...]
> which is invalid C syntax. ##' gets rid of the comma, so we get the
> following instead:
>
> fprintf (stderr, "success!\n")
>
>
> Which is not the case. That bug breaks
Package: cpp-2.95
Version: 1:2.95.4-10
Severity: important
Given the sample code (extracted from the Linux kernel sources):
#include
#define DRM_NAME "drm"
#define KERN_ERR "<7>"
#define DRM_ERROR(fmt, args...) \
printf(KERN_ERR "[" DRM_NAME ":%s] *ERROR* " fmt , __FUNCTION__, ##
args)
Brendan O'Dea writes:
> More info: this error does not occur when building without -Duse64bitint.
please could you recheck with gcc-3.1 please?
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
(new) cpp-3.1_3.1.1-1_hppa.deb standard interpreters
WARNING: Already present in main distribution.
The GNU C preprocessor.
The GNU C preprocessor is a macro processor that is used automatically
by the GNU C compiler to transform programs before actual compilation.
.
This package has been separ
cpp-3.1-doc_3.1.1-1_all.deb
to pool/main/g/gcc-3.1/cpp-3.1-doc_3.1.1-1_all.deb
cpp-3.1_3.1.1-1_i386.deb
to pool/main/g/gcc-3.1/cpp-3.1_3.1.1-1_i386.deb
fastjar_3.1.1-1_i386.deb
to pool/main/g/gcc-3.1/fastjar_3.1.1-1_i386.deb
fixincludes_3.1.1-1_i386.deb
to pool/main/g/gcc-3.1/fixincludes_3.
>Submitter-Id: net
>Originator:Akim Demaille
>Organization:
>Confidential: no
>Synopsis: Invoking (template?) ctors as Class::Class is accepted
>Severity: serious
>Priority: low
>Category: c++
>Class: accepts-illegal
>Release: 3.1.1 20020606 (Debian prerel
18 matches
Mail list logo
