January 30, 2015
Hot Topics:

Utility Libraries for BREW-Compilation Pitfalls

  • June 3, 2003
  • By Radu Braniste
  • Send Email »
  • More Articles »


This article describes possible problems encountered when compiling the BREW utility library using ARM ADS1.x compilers and how to avoid them. An ADS1.0.1 conformant library is attached for downloading.


There are basically three main problems (numbers 3 and 4 have the same cause):

Problem Number Problem Name Location Description
1 platformSpecific.h Line 12 Error: C2991E: linkage disagreement for 'operator new(unsigned int)'—treated as 'extern'
2 BrewString.h Line 59 Fatal error: Internal fault: 0x5ffa
3 BrewString.h Line 475 Error: C2457E: undeclared name, inventing 'extern "C" int opPlusImpl(...);'
4 BrewString.h Line 475 Serious error: C2587E: non-POD object cannot be passed as '...' argument

Cause and Cure

The linkage disagreement is mainly due to the fact that the global overload of operator new & delete on ARM is defined as:

void* operator new (size_t size);
void operator delete (void *p);

As a quick reminder, operator new & delete can be overloaded at global or on a per-class basis, as in:

class C
static void* operator new (size_t size); 
static void operator delete (void *p);

There are obvious disadvantages in using class level in BREW (what happens with POD?); the global alternative is preferred. The only problem with the global approach is when the overload is referenced from more than one translation unit, resulting in compilation errors on ARM. As static cannot be used, we can use inline, as in this code snippet:

typedef unsigned int UINT;
  inline void* operator new(UINT size);
  inline void operator delete(void * ptr);

This is a non-standard use assuming internal linkage (the standard indicates that inline has external linkage, but there are not too many conformant compilers). It's interesting to notice that assuming 'unsigned long' for size_t results in a "Non-RWPI Section" linkage error.

An internal fault is more complicated because we are in the unchartered territories of template standardization. Basically, the cause is a minuscule default template parameter used in BrewString—and default parameters are not supported by ADS 1.x compilers. The following piece of code:

template <class T = int>
class X{}

generates the internal fault. The problem was solved (as well as other standard compliancy problems) in the newest released RealView Compilation Tools 2.0.

opPlusImpl errors are related to 'friend' support in ADS. opPlusImpl has to have the fully qualified name, as in:

friend BrewString<T> operator+ ( const T* lhs,
                                 const BrewString<T>& rhs )
    return BrewString<T>::opPlusImpl(lhs, rhs);

An interesting fact is that ADS has standard support for friend templates. See http://gcc.gnu.org/fom_serv/cache/32.html for a description.

As mentioned before, the new 2.0 compiler has important bug fixes, especially in templates support and has to be preferred for development. For compatibility, the attached code was compiled using ADS1.0.1 and BREW1.0 (that's why there are STRLOWER and STRUPPER definitions).

In Conclusion

I want to say "Thank you" to all the readers who diligently have tested the code. Your observations and suggestions are at the basis of this article.

About the Author

Radu Braniste is Director of Technology at Epicad. He can be contacted at rbraniste@epicad.com

# # #

Comment and Contribute


(Maximum characters: 1200). You have characters left.



Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Sitemap | Contact Us

Thanks for your registration, follow us on our social networks to keep up-to-date
Rocket Fuel