Sivaprasad.pv wrote:
Hi Kai Ruottu,
Thanks for your suggestion.As you have suggested i have followed
the order for building.But Amongst the 3 steps I have completed the
first 2 steps. now i want to build libraries like libstdc++ .I have
gone through the libstdc++-v3 porting document from url
"gcc.gnu.org/onlinedocs/porting".From that I think, I have to add
atomicity.h file for our target(proprietary processor).but i want to
know in detail about atomicity.h file so can you please suggest me
any document which will help me to porting libstdc++.
I myself would be in the same situation with you in this if needing to
do this :( A Google search with "porting atomicity.h" gave as the first
hit the:
http://gcc.gnu.org/onlinedocs/porting/Thread-safety.html
and this then tells :
"The C++ library string functionality requires a couple of atomic
operations to provide thread-safety. If you don't take any special action,
the library will use stub versions of these functions that are not
thread-safe. They will work fine, unless your applications are
multi-threaded."
I would interpret this meaning that if no special CPU-specific directory
does exist, then stub functions (replacements doing nothing) will be used.
And so producing a "prototype" libstdc++ without support for
multithreading should succeed... In any case using Google etc with
something like
those words I used could be useful and then looking at what was found!
configuration options used for building c++ compiler :
$SRC/gcc-3.3/configure --prefix=$RELDIR --target=$TARGET
--enable-languages=c++ --with-newlib --with-gnu-as --with-gnu-ld
--host=i686-pc-linux-gnu --enable-sjlj-exceptions --with-dwarf2
I could consider leaving the two last options away, using the defaults,
for a prototype C/C++ compiler, until knowing what they are used for. The
'--with-gnu-as/ld' then are used at configure time to choose between
some non-GNU tools and GNU tools. If there is no use for them like choosing
between different config headers, these two are really vain. With
targets which have proprietary native 'as' and 'ld', these then may be
obligatory
even with crosscompilers, there isn't any automatic "choose the GNU
ones" mechanism for the GNU-only crosstoolchains. Using them always
with crosstoolchains then may be motivated, but sometimes they are vain....
make all-gcc
make install-gcc
configuration options used for building newlib:
$SRC/newlib-1.11.0/configure --prefix=$RELDIR --target=$TARGET
--host=i686-pc-linux-gnu
make all install
When having both the C compiler and the C library, compiling and linking
a "Hello World" level executable should work. But this then requires
having suitable startups ('crt0.o', 'crti.o', 'crtn.o') and a suitable
linker script for some target board or simulator. Basically the
'libgloss' ("glue
library") part in newlib should provide that CPU/board specific support
things. The '--with-newlib' however should remove all link tests from
the libiberty and libstdc++ configures, so producing these libraries
will work without linkings succeeding, but some day one probably needs to
get also the linkings to work... Probably you would need to look at
those startups and linker scripts too :(
