This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: C++ porting : No such file or directory


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




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]