bastring.cc

bastring.cc

[Jeffrey A Law]

Is user code supposed to be able to include this file directly?

If yes, is bastring.cc supposed to handle multiple inclusions?

guavac in the RedHat 5.1 distribution doesn't build because the
compiler chokes because bastring.cc gets included twice.  The compiler
complains about redefinitions of stuff defined in bastring.cc.

This happens because common/unicode_string.h includes "cppstring.h"
which includes "string", which includes "bastring.h", which
includes "bastring.cc".

common/unicode_string.h then proceeds to include "bastring.cc" on
its own.


jeff

Re: bastring.cc

[Jason Merrill]

>>>>> Jeffrey A Law <law@cygnus.com> writes:

 > Is user code supposed to be able to include this file directly?

No.

Jason

Re: bastring.cc

[Jason Merrill]

>>>>> Alexandre Oliva <oliva@dcc.unicamp.br> writes:

 > Jeffrey A Law <law@cygnus.com> writes:
 >> Is user code supposed to be able to include this file directly?

 > As Jason, wrote, this is not supposed to work with the current and
 > correct approach of egcs to include bastring.cc in bastring.h.
 > Unfortunately, it was necessary to include it on some platforms such
 > as IRIX 5.2, SunOS 4.1.3 and Cygnus/GNU-Win32, that would not work
 > without bastring.cc explicitly included in every translation unit that
 > would require some symbol defined within it.

Huh?  Why?  Why didn't anyone mention this to the g++ team?

Jason

Re: bastring.cc

[Jeffrey A Law]

  In message < orbtpbf478.fsf@iguacu.dcc.unicamp.br >you write:
  > A `configure' has was placed to check whether the #include was needed,
  > and it is *not* including bastring.cc twice, except in
  > UnicodeInstantiation.C, that is not included elsewhere.  I completely
  > removed the inclusions of bastring.cc, even from
  > UnicodeInstatiation.C, and I got exactly the same error, so the
  > problem must be elsewhere.
I only had to change one file in the guavac-1.1-2 source RPM on my
RedHat 5.1 CD to fix this problem.  After fixing that one file it
built just fine.

jeff

Re: bastring.cc

[Jason Merrill]

>>>>> Alexandre Oliva <oliva@dcc.unicamp.br> writes:

 > Jason Merrill <jason@cygnus.com> writes:
 >>>>>>> Alexandre Oliva <oliva@dcc.unicamp.br> writes:
 >>> Jeffrey A Law <law@cygnus.com> writes:
 >>>> Is user code supposed to be able to include this file directly?

 >>> As Jason, wrote, this is not supposed to work with the current and
 >>> correct approach of egcs to include bastring.cc in bastring.h.
 >>> Unfortunately, it was necessary to include it on some platforms such
 >>> as IRIX 5.2, SunOS 4.1.3 and Cygnus/GNU-Win32, that would not work
 >>> without bastring.cc explicitly included in every translation unit that
 >>> would require some symbol defined within it.

 >> Huh?  Why?  Why didn't anyone mention this to the g++ team?

 > I did, and that's why bastring.h now includes bastring.cc.  And I
 > suggested a temporary forward-compatible work-around for this problem
 > for both guavac and lilypond.

You shouldn't be #including bastring.h, either.  <string> is the header you
want.

Jason

Re: bastring.cc

[Alexandre Oliva]

Jeffrey A Law <law@cygnus.com> writes:

> Is user code supposed to be able to include this file directly?

> If yes, is bastring.cc supposed to handle multiple inclusions?

As Jason, wrote, this is not supposed to work with the current and
correct approach of egcs to include bastring.cc in bastring.h.
Unfortunately, it was necessary to include it on some platforms such
as IRIX 5.2, SunOS 4.1.3 and Cygnus/GNU-Win32, that would not work
without bastring.cc explicitly included in every translation unit that
would require some symbol defined within it.

A `configure' has was placed to check whether the #include was needed,
and it is *not* including bastring.cc twice, except in
UnicodeInstantiation.C, that is not included elsewhere.  I completely
removed the inclusions of bastring.cc, even from
UnicodeInstatiation.C, and I got exactly the same error, so the
problem must be elsewhere.

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: bastring.cc

[Alexandre Oliva]

Jason Merrill <jason@cygnus.com> writes:

>>>>>> Alexandre Oliva <oliva@dcc.unicamp.br> writes:
>> Jeffrey A Law <law@cygnus.com> writes:
>>> Is user code supposed to be able to include this file directly?

>> As Jason, wrote, this is not supposed to work with the current and
>> correct approach of egcs to include bastring.cc in bastring.h.
>> Unfortunately, it was necessary to include it on some platforms such
>> as IRIX 5.2, SunOS 4.1.3 and Cygnus/GNU-Win32, that would not work
>> without bastring.cc explicitly included in every translation unit that
>> would require some symbol defined within it.

> Huh?  Why?  Why didn't anyone mention this to the g++ team?

I did, and that's why bastring.h now includes bastring.cc.  And I
suggested a temporary forward-compatible work-around for this problem
for both guavac and lilypond.

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil