Re: Building C++ application for eCos on ARM

[Uwe Kindler <uwe_kindler at web dot de>]

Hi,

ext/atomicity.h is a GCC specific extension of the STL library - so it is not supported by ustl. You could try to implement the functionality provided by atomicity.h header by yourself - but most likely you will run into the next error afterwards caused by the next missing file that is GCC specific.

Maybe you should switch to an embedded Linux instead of eCos if this is possible. Then you have full STL support. If you do not develop a consumer product where every cent counts, a Linux might be the better choice?

Kind regards, Uwe



Am 18.09.2013 15:18, schrieb Jabran Bhatti:
> Hello John/cetoni,
>
> Thanks for your replies.
>
> * I tried the stl compatibility layer solution and all goes well until
> I get the following error:
>
> /usr/local/include/ptlib/critsec.h:37:30: fatal error:
> ext/atomicity.h: No such file or directory
>
> It appears that the ptlib library also requires header files that are
> actually extensions of STL (header files in the folder ext/). These
> extensions are not defined in ustl, which means this solution will not
> work. Am I right?
>
> * I also tried to build a toolchain including Erik Aagaard Knudsen's
> libstdc++ for eCos (as described in the file
> eCos_libstdcxx_compatibility/libstdcxx_compatibility.eak). Here, I
> encountered the following problem:  when configuring GCC (4.3.2.), I
> get a warning that most of the options such as --enable-languages,
> --with-gnu-as, --with-gnu-ld, --with-newlib,... are not recognized.
> When i try to build and install GCC next, I get a whole bunch of
> assembler messages as follows:
>
> /usr/src/gcc-4.3.2/libiberty/regex.c: In function ‘xregerror’:
>
> /usr/src/gcc-4.3.2/libiberty/regex.c:8089: warning: implicit
> declaration of function ‘mempcpy’
>
> /usr/src/gcc-4.3.2/libiberty/regex.c:8089: warning: incompatible
> implicit declaration of built-in function ‘mempcpy’
>
> /tmp/ccNe5Dme.s: Assembler messages:
>
> /tmp/ccNe5Dme.s:5991: Error: r13 not allowed here -- `lsr r3,sp,#3'
>
> /tmp/ccNe5Dme.s:6498: Error: r13 not allowed here -- `rsb sp,r3,sp'
>
> /tmp/ccNe5Dme.s:6500: Error: r13 not allowed here -- `lsr r0,sp,#3'
>
> I think these errors might be caused by a conflict between my native
> GCC compiler (4.8) and gcc-4.3.2.
> So I tried to install gcc-4.3.2 on my machine (32-bit ubuntu 12.04)
> from source (since it's no longer available on aptitude). Here, I
> encountered a known bug in the linker step
> (https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/738098). The
> workaround described here didn't work for me.
>
> What do you guys think?
>
> 2013/9/17 cetoni GmbH - Uwe Kindler <uwe.kindler@cetoni.de>:
> > Hi,
> >
> > we also had an own library that uses stl and we managed to build it for eCos
> > uSTL. We did the following
> >
> > 1.
> > We created an stl compatibility layer: a folder that contains the stl
> > include files for eCos:
> > vector
> > string
> > map
> > ...
> >
> > 2.
> > Each of these include files contains the same content - it simply includes
> > ustl_compat.h file
> >
> > #ifndef ustl_compat_vectorH
> > #define ustl_compat_vectorH
> > #include "ustl_compat.h"
> >
> > #endif
> >
> > 3.
> > The ustl_compat.h file contains the following code:
> >
> > #ifndef ustl_compatH
> > #define ustl_compatH
> > #include <ustl.h>
> >
> > #define std ustl
> >
> > #endif // ustl_compatH
> >
> >
> > So it simply includes the ustl.h header file and defines the preprocessor
> > macro std. So each occurence of std::vector will be replaced by ustl::vector
> >
> > This worked for us and we could compile the library.

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss