[Buildroot] Problem #including <string>

[Buildroot] Problem #including <string>

[Will Wagner]

Hello,

I have built buildroot with the attached config for x86, with support 
for c++.

However whenever I include <string> I get errors in my code because it 
seems somewhere in <string> it is #defining index.

If I attempt to compile the following code:

#ifdef index
#error foo
#endif

#include <string>

#ifdef index
#error bar
#endif

void do_nothing()
{
}

Then I get the second error.

I have tried searching through the headers to find where the #define 
index is but I have been unable to find it. Can anyone suggest the best 
way of locating where index is being erroneously defined?

Many thanks,

Will.

-- 
------------------------------------------------------------------------
Will Wagner                                     will_wagner at carallon.com
Senior Project Engineer                  Office Tel: +44 (0)20 7371 2032
Carallon Ltd, Studio G20, Shepherds Building, Rockley Rd, London W14 0DA
------------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config
Type: application/xml
Size: 14551 bytes
Desc: not available
Url : http://busybox.net/lists/buildroot/attachments/20070829/aa8a1ec6/attachment-0001.xml 

[Buildroot] Problem #including <string>

[Carmelo AMOROSO]

Will Wagner wrote:
> Hello,
>
> I have built buildroot with the attached config for x86, with support 
> for c++.
>
> However whenever I include <string> I get errors in my code because it 
> seems somewhere in <string> it is #defining index.
>
> If I attempt to compile the following code:
>
> #ifdef index
> #error foo
> #endif
>
> #include <string>
>
> #ifdef index
> #error bar
> #endif
>
> void do_nothing()
> {
> }
>
> Then I get the second error.
>
> I have tried searching through the headers to find where the #define 
> index is but I have been unable to find it. Can anyone suggest the 
> best way of locating where index is being erroneously defined?
>
> Many thanks,
>
> Will.
>
Probably you have uClibc built with SUSv3_MACRO defined (among these 
there is index )

Cheers,
Carmelo
> ------------------------------------------------------------------------
>
> _______________________________________________
> buildroot mailing list
> buildroot at uclibc.org
> http://busybox.net/mailman/listinfo/buildroot

[Buildroot] Problem #including <string>

[Carmelo AMOROSO]

Will Wagner wrote:
> Carmelo AMOROSO wrote:
>> Probably you have uClibc built with SUSv3_MACRO defined (among these 
>> there is index )
>>
>> Cheers,
>> Carmelo
>>> ------------------------------------------------------------------------ 
>>>
>
> Thank you that fixed it. Why would you want the SUSv3_MACRO defined?
>
If some applications still call the legacy SUSv3 api, you may need
to enable this option within uClibc, anyway, just to avoid name clashing
when building some application (in your case), it's better to use
the function version of the SUSv3 api and not macros... (if cannot patch 
the application)

but if you doesn't needs this interfaces, safely remove this support 
from uClibc.

Carmelo

P.S.
CC the buildroot ML to get other feedbacks it is the case

[Buildroot] Problem #including <string>

[Bernhard Fischer]

On Wed, Aug 29, 2007 at 03:41:36PM +0200, Carmelo AMOROSO wrote:
>Will Wagner wrote:
>> Carmelo AMOROSO wrote:
>>> Probably you have uClibc built with SUSv3_MACRO defined (among these 
>>> there is index )
>>>
>>> Cheers,
>>> Carmelo
>>>> ------------------------------------------------------------------------ 
>>>>
>>
>> Thank you that fixed it. Why would you want the SUSv3_MACRO defined?

You don't want UCLIBC_SUSV3_LEGACY_MACROS nor UCLIBC_SUSV3_LEGACY, as a
general rule of thumb.
>>
>If some applications still call the legacy SUSv3 api, you may need
>to enable this option within uClibc, anyway, just to avoid name clashing
>when building some application (in your case), it's better to use
>the function version of the SUSv3 api and not macros... (if cannot patch 
>the application)
>
>but if you doesn't needs this interfaces, safely remove this support 
>from uClibc.