C++ porting : No such file or directory

[Kai Ruottu]

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 :(