as problem on sgi

as problem on sgi

[Sami Romdhani]

Hi,

I have a problem with as on an SGi Octane workstation running Irix 6.5.
I compiled my code with both egcs-2.91.60 and gcc 2.8.1. It compiles
perfectly well on linux and solaris, however when I try to compile it on
SGi, I get such errors :

as: Error: /var/tmp/cca006yO.s, line 12348: Truncating token:
__t7rb_tree5Zt12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc\
_template2b0i0Zt4pair2ZCt12basic_string3ZcZt18string_char_traits1ZcZt24__de\
fault_alloc_template2b0i0Zt12basic_string3ZcZt18string_char_traits1ZcZt24__\
default_alloc_template2b0i0Zt9select1st1Zt4pair2ZCt12basic_string3ZcZt18string\
_char_traits1ZcZt24__default_alloc_template2b0i0Zt12basic_string3ZcZt18string\
_char_traits1ZcZt24__default_alloc_template2b0i0Zt4less1Zt12basic_string3ZcZt\
18string_char_traits1ZcZt24__default_alloc_template2b0i0Zt24__default_alloc_\
template2b0i0RCt7rb_tree5Zt12basic_string3ZcZt18string_char_traits1ZcZt24__de\
fault_alloc_template2b0i0Zt4pair2ZCt12basic_string3ZcZt18string_char_traits1Z\
cZt24__default_alloc_template2b0i0Zt12basic_string3ZcZt18string_char_traits1Z\
cZt24__default_alloc_template2b0i0Zt9select1st1Zt4pair2ZCt12basic_string3ZcZ\
t18string_char_traits1ZcZt24__default_alloc_template2b0i0Zt12basic_string3ZcZ\
t18string_char_traits1ZcZt24__default_alloc_template2b0i0Zt4less1Zt12basic_st\
ring3ZcZt18string_char_traits
      .end
__t7rb_tree5Zt12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_\
template2b0i0Zt4pair2ZCt12basic_string3ZcZt18string_char_traits1ZcZt24__defau\
lt_alloc_template2b0i0Zt12basic_string3ZcZt18string_char_traits1ZcZt24__defau\
lt_alloc_template2b0i0Zt9select1st1Zt4pair2ZCt12basic_string3ZcZt18string_cha\
r_traits1ZcZt24__default_alloc_template2b0i0Zt12basic_string3ZcZt18string_cha\
r_traits1ZcZt24__default_alloc_template2b0i0Zt4less1Zt12basic_string3ZcZt18st\
ring_char_traits1ZcZt24__default_alloc_template2b0i0Zt24__default_alloc_templ\
ate2b0i0RCt7rb_tree5Zt12basic_string3ZcZt18string_char_traits1ZcZt24__default\
_alloc_template2b0i0Zt4pair2ZCt12basic_string3ZcZt18string_char_traits1ZcZt24\
__default_alloc_template2b0i0Zt12basic_string3ZcZt18string_char_traits1ZcZt24\
__default_alloc_template2b0i0Zt9select1st1Zt4pair2ZCt12basic_string3ZcZt18str\
ing_char_traits1ZcZt24__default_alloc_template2b0i0Zt12basic_string3ZcZt18str\
ing_char_traits1ZcZt24__default_alloc_template2b0i0Zt4less1Zt12basic_string3Z\
cZt18string_char_traits1ZcZt24__default_alloc_tem


And it goes on, and on, and on ...

gas is not installed on SGi Irix 6.5, I use instead the SGi's as. Indeed
I read many times on mailing list that the as of Irix 6 and above should
work with egcs and gcc. (And actually I did not find any gas version for
Irix).

I would *really* like to be able to compile my code on irix, so any help
would be greatly appreciated.

Not that some code would compile and some other wouldn't.


Sami.
-- 
Sami Romdhani
PhD Student, University of Westminster
Harrow School of Computer Science
Watford Road, Northwick Park
Harrow HA3 1TP, UK
Tel 44-171-911.5000 ext 4226
Fax 44-171-911.5906

Re: as problem on sgi

[Martin v. Loewis]

> I have a problem with as on an SGi Octane workstation running Irix 6.5.

An introductory answer for this is found on
http://egcs.cygnus.com/faq.html#squangle

Regards,
Martin

Re: as problem on sgi

[Paul Derbyshire]

At 05:36 PM 2/20/99 +0100, you wrote:
>> I have a problem with as on an SGi Octane workstation running Irix 6.5.
>
>An introductory answer for this is found on
> http://egcs.cygnus.com/faq.html#squangle

It didn't look to me like the C++ symbol was just too long for the
assembler; it looked to me like the symbol was ridiculously long and
repetitive. It seemed to be the same few components repeated dozens of
times, which looks like a symbol generation error... should a symbol really
be output with that many repetitions of "string_char_traits" inside of it?

-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: as problem on sgi

[Gerald Pfeifer]

On Sat, 20 Feb 1999, Paul Derbyshire wrote:
>> An introductory answer for this is found on
>> http://egcs.cygnus.com/faq.html#squangle
> It didn't look to me like the C++ symbol was just too long for the
> assembler; it looked to me like the symbol was ridiculously long and
> repetitive. It seemed to be the same few components repeated dozens of
> times, which looks like a symbol generation error... should a symbol really
> be output with that many repetitions of "string_char_traits" inside of it?

That's exactly the point of -fsquangle, which is mentioned in the FAQ
entry above.

Note that symbols of these kind mostly happen with template heavy
libraries like STL & Co, which are rather "new". -fsquangle makes
the generated symbols significantly shorter, but it breaks link 
compatiblity and thus will be only enabled together with the new C++
ABI. (One does not want to break link compatibility too often...)

Gerald
-- 
Gerald Pfeifer (Jerry)      Vienna University of Technology
pfeifer@dbai.tuwien.ac.at   http://www.dbai.tuwien.ac.at/~pfeifer/

Re: as problem on sgi

[Paul Derbyshire]

At 01:48 AM 2/21/99 +0100, you wrote:
>Note that symbols of these kind mostly happen with template heavy
>libraries like STL & Co, which are rather "new". -fsquangle makes
>the generated symbols significantly shorter, but it breaks link 
>compatiblity and thus will be only enabled together with the new C++
>ABI. (One does not want to break link compatibility too often...)

New C++ ABI?

On a side note: Why is glibc gone... "political reasons"??? It's open
source software for heaven's sake.
-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: as problem on sgi

[Paul Derbyshire]

At 06:32 PM 2/20/99 -0700, you wrote:
From time to time it is necessary to break link compatability -- for
>example the new mangling schemes, improved exception handling mechanisms,
>changes in the vtable layout, thunks, etc.
>
>The pending set of changes is usually refered to as the "New C++ ABI".

Ah...

>Take it up with RMS.

RMS?

-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: as problem on sgi

[Paul Derbyshire]

At 08:46 PM 2/20/99 -0500, you wrote:
>On Sat, 20 Feb 1999 20:42:16 -0500, Paul Derbyshire wrote:
>>>Take it up with RMS.
>>
>>RMS?
>
>Argh.  Go away and don't come back till you've memorized the Jargon
>File.  And stop asking these dumb questions.  I've been arguing with
>RMS all week about libc and I'm in a rotten mood, and egcs@ is
>supposed to be a development list not a stupid questions list.

I have memorized the Jargon File (as of version 3 IIRC, the copy on
lysator.edu's Web server), and there is no entry for RMS in it :-)
Unless they finally got around to updating it sometime in the last 18
months, for the first time in about 6 years. :-)

-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: as problem on sgi

[Gerald Pfeifer]

On Sat, 20 Feb 1999, Paul Derbyshire wrote:
> I have memorized the Jargon File (as of version 3 IIRC, the copy on
> lysator.edu's Web server), and there is no entry for RMS in it :-)

To the list, so that this thread can finally die:

  http://www.gnu.org/people/rms.html

Gerald
-- 
Gerald Pfeifer (Jerry)      Vienna University of Technology
pfeifer@dbai.tuwien.ac.at   http://www.dbai.tuwien.ac.at/~pfeifer/

Re: as problem on sgi

[Jeffrey A Law]

  In message < 3.0.6.32.19990220195214.00860750@pop.globalserve.net >you write:
  > New C++ ABI?

Re: as problem on sgi

[Paul Derbyshire]

At 08:46 PM 2/20/99 -0500, you wrote:
>On Sat, 20 Feb 1999 20:42:16 -0500, Paul Derbyshire wrote:
>>>Take it up with RMS.
>>
>>RMS?
>
>Argh.  Go away and don't come back till you've memorized the Jargon
>File.  And stop asking these dumb questions.  I've been arguing with
>RMS all week about libc and I'm in a rotten mood, and egcs@ is
>supposed to be a development list not a stupid questions list.

I have memorized the Jargon File (as of version 3 IIRC, the copy on
lysator.edu's Web server), and there is no entry for RMS in it :-)
Unless they finally got around to updating it sometime in the last 18
months, for the first time in about 6 years. :-)

-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: as problem on sgi

[Paul Derbyshire]

At 05:36 PM 2/20/99 +0100, you wrote:
>> I have a problem with as on an SGi Octane workstation running Irix 6.5.
>
>An introductory answer for this is found on
> http://egcs.cygnus.com/faq.html#squangle

It didn't look to me like the C++ symbol was just too long for the
assembler; it looked to me like the symbol was ridiculously long and
repetitive. It seemed to be the same few components repeated dozens of
times, which looks like a symbol generation error... should a symbol really
be output with that many repetitions of "string_char_traits" inside of it?

-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: as problem on sgi

[Paul Derbyshire]

At 06:32 PM 2/20/99 -0700, you wrote:
From time to time it is necessary to break link compatability -- for
>example the new mangling schemes, improved exception handling mechanisms,
>changes in the vtable layout, thunks, etc.
>
>The pending set of changes is usually refered to as the "New C++ ABI".

Ah...

>Take it up with RMS.

RMS?

-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: as problem on sgi

[Gerald Pfeifer]

On Sat, 20 Feb 1999, Paul Derbyshire wrote:
>> An introductory answer for this is found on
>> http://egcs.cygnus.com/faq.html#squangle
> It didn't look to me like the C++ symbol was just too long for the
> assembler; it looked to me like the symbol was ridiculously long and
> repetitive. It seemed to be the same few components repeated dozens of
> times, which looks like a symbol generation error... should a symbol really
> be output with that many repetitions of "string_char_traits" inside of it?

That's exactly the point of -fsquangle, which is mentioned in the FAQ
entry above.

Note that symbols of these kind mostly happen with template heavy
libraries like STL & Co, which are rather "new". -fsquangle makes
the generated symbols significantly shorter, but it breaks link 
compatiblity and thus will be only enabled together with the new C++
ABI. (One does not want to break link compatibility too often...)

Gerald
-- 
Gerald Pfeifer (Jerry)      Vienna University of Technology
pfeifer@dbai.tuwien.ac.at   http://www.dbai.tuwien.ac.at/~pfeifer/

as problem on sgi

[Sami Romdhani]

Hi,

I have a problem with as on an SGi Octane workstation running Irix 6.5.
I compiled my code with both egcs-2.91.60 and gcc 2.8.1. It compiles
perfectly well on linux and solaris, however when I try to compile it on
SGi, I get such errors :

as: Error: /var/tmp/cca006yO.s, line 12348: Truncating token:
__t7rb_tree5Zt12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc\
_template2b0i0Zt4pair2ZCt12basic_string3ZcZt18string_char_traits1ZcZt24__de\
fault_alloc_template2b0i0Zt12basic_string3ZcZt18string_char_traits1ZcZt24__\
default_alloc_template2b0i0Zt9select1st1Zt4pair2ZCt12basic_string3ZcZt18string\
_char_traits1ZcZt24__default_alloc_template2b0i0Zt12basic_string3ZcZt18string\
_char_traits1ZcZt24__default_alloc_template2b0i0Zt4less1Zt12basic_string3ZcZt\
18string_char_traits1ZcZt24__default_alloc_template2b0i0Zt24__default_alloc_\
template2b0i0RCt7rb_tree5Zt12basic_string3ZcZt18string_char_traits1ZcZt24__de\
fault_alloc_template2b0i0Zt4pair2ZCt12basic_string3ZcZt18string_char_traits1Z\
cZt24__default_alloc_template2b0i0Zt12basic_string3ZcZt18string_char_traits1Z\
cZt24__default_alloc_template2b0i0Zt9select1st1Zt4pair2ZCt12basic_string3ZcZ\
t18string_char_traits1ZcZt24__default_alloc_template2b0i0Zt12basic_string3ZcZ\
t18string_char_traits1ZcZt24__default_alloc_template2b0i0Zt4less1Zt12basic_st\
ring3ZcZt18string_char_traits
      .end
__t7rb_tree5Zt12basic_string3ZcZt18string_char_traits1ZcZt24__default_alloc_\
template2b0i0Zt4pair2ZCt12basic_string3ZcZt18string_char_traits1ZcZt24__defau\
lt_alloc_template2b0i0Zt12basic_string3ZcZt18string_char_traits1ZcZt24__defau\
lt_alloc_template2b0i0Zt9select1st1Zt4pair2ZCt12basic_string3ZcZt18string_cha\
r_traits1ZcZt24__default_alloc_template2b0i0Zt12basic_string3ZcZt18string_cha\
r_traits1ZcZt24__default_alloc_template2b0i0Zt4less1Zt12basic_string3ZcZt18st\
ring_char_traits1ZcZt24__default_alloc_template2b0i0Zt24__default_alloc_templ\
ate2b0i0RCt7rb_tree5Zt12basic_string3ZcZt18string_char_traits1ZcZt24__default\
_alloc_template2b0i0Zt4pair2ZCt12basic_string3ZcZt18string_char_traits1ZcZt24\
__default_alloc_template2b0i0Zt12basic_string3ZcZt18string_char_traits1ZcZt24\
__default_alloc_template2b0i0Zt9select1st1Zt4pair2ZCt12basic_string3ZcZt18str\
ing_char_traits1ZcZt24__default_alloc_template2b0i0Zt12basic_string3ZcZt18str\
ing_char_traits1ZcZt24__default_alloc_template2b0i0Zt4less1Zt12basic_string3Z\
cZt18string_char_traits1ZcZt24__default_alloc_tem


And it goes on, and on, and on ...

gas is not installed on SGi Irix 6.5, I use instead the SGi's as. Indeed
I read many times on mailing list that the as of Irix 6 and above should
work with egcs and gcc. (And actually I did not find any gas version for
Irix).

I would *really* like to be able to compile my code on irix, so any help
would be greatly appreciated.

Not that some code would compile and some other wouldn't.


Sami.
-- 
Sami Romdhani
PhD Student, University of Westminster
Harrow School of Computer Science
Watford Road, Northwick Park
Harrow HA3 1TP, UK
Tel 44-171-911.5000 ext 4226
Fax 44-171-911.5906

Re: as problem on sgi

[Paul Derbyshire]

At 01:48 AM 2/21/99 +0100, you wrote:
>Note that symbols of these kind mostly happen with template heavy
>libraries like STL & Co, which are rather "new". -fsquangle makes
>the generated symbols significantly shorter, but it breaks link 
>compatiblity and thus will be only enabled together with the new C++
>ABI. (One does not want to break link compatibility too often...)

New C++ ABI?

On a side note: Why is glibc gone... "political reasons"??? It's open
source software for heaven's sake.
-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  | http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|

Re: as problem on sgi

[Martin v. Loewis]

> I have a problem with as on an SGi Octane workstation running Irix 6.5.

An introductory answer for this is found on
http://egcs.cygnus.com/faq.html#squangle

Regards,
Martin

Re: as problem on sgi

[Gerald Pfeifer]

On Sat, 20 Feb 1999, Paul Derbyshire wrote:
> I have memorized the Jargon File (as of version 3 IIRC, the copy on
> lysator.edu's Web server), and there is no entry for RMS in it :-)

To the list, so that this thread can finally die:

  http://www.gnu.org/people/rms.html

Gerald
-- 
Gerald Pfeifer (Jerry)      Vienna University of Technology
pfeifer@dbai.tuwien.ac.at   http://www.dbai.tuwien.ac.at/~pfeifer/

Re: as problem on sgi

[Joe Buck]

Mike Stump writes:

> Do we need a talk.egcs?  (Or egcs-help if you prefer.)

I don't think so.

Folks should feel free to use the existing gcc-help list (gatewayed
to the newsgroup gnu.gcc.help), or g++-help / gnu.g++.help for C++
questions, even if egcs-specific.

Re: as problem on sgi

[Mike Stump]

> Date: Sat, 20 Feb 1999 19:52:14 -0500
> To: egcs@egcs.cygnus.com
> From: Paul Derbyshire <pderbysh@usa.net>

> New C++ ABI?

I'll refer you to the documentation.  We wrote it so that you can read
it.  While I wish that we had large amount of time so that we can
spoon feed everyone that has questions to just ask us instead of
having to try and find the answer in the documentation, unfortunately
on the planert we live on, time is money and there are way too many
users to help them all by answering such questions.

> On a side note: Why is glibc gone... "political reasons"??? It's open
> source software for heaven's sake.

I too am slightly interested in this, but political discussions of
other random packages don't below on egcs.  It is therefore also wrong
to ask for such a discussion.

egcs is for disscussion of compilers (if you want to broaden it some)
and the particular compiler hosted by the sites listed at
egcs.cygnus.com, postings other that those that deal with the
technical details of compilers, don't belong here.  Could you please
try and limit topics discussed to egcs please, thanks.  egcs is
already high enough volume without having other random topics on it.
If left unchecked, we are in danger of loosing compiler experts
because the volume is too high and of too low quality.  Help us keep
the quality of the list high.

Do we need a talk.egcs?  (Or egcs-help if you prefer.)

Re: as problem on sgi

[Joe Buck]

Mike Stump writes:

> Do we need a talk.egcs?  (Or egcs-help if you prefer.)

I don't think so.

Folks should feel free to use the existing gcc-help list (gatewayed
to the newsgroup gnu.gcc.help), or g++-help / gnu.g++.help for C++
questions, even if egcs-specific.

Re: as problem on sgi

[Mike Stump]

> Date: Sat, 20 Feb 1999 19:52:14 -0500
> To: egcs@egcs.cygnus.com
> From: Paul Derbyshire <pderbysh@usa.net>

> New C++ ABI?

I'll refer you to the documentation.  We wrote it so that you can read
it.  While I wish that we had large amount of time so that we can
spoon feed everyone that has questions to just ask us instead of
having to try and find the answer in the documentation, unfortunately
on the planert we live on, time is money and there are way too many
users to help them all by answering such questions.

> On a side note: Why is glibc gone... "political reasons"??? It's open
> source software for heaven's sake.

I too am slightly interested in this, but political discussions of
other random packages don't below on egcs.  It is therefore also wrong
to ask for such a discussion.

egcs is for disscussion of compilers (if you want to broaden it some)
and the particular compiler hosted by the sites listed at
egcs.cygnus.com, postings other that those that deal with the
technical details of compilers, don't belong here.  Could you please
try and limit topics discussed to egcs please, thanks.  egcs is
already high enough volume without having other random topics on it.
If left unchecked, we are in danger of loosing compiler experts
because the volume is too high and of too low quality.  Help us keep
the quality of the list high.

Do we need a talk.egcs?  (Or egcs-help if you prefer.)