Re: Porting libstdc++ to custom OS?

[Fery <engard dot ferenc at innomed dot hu>]

Jonathan Wakely wrote:

> > I use a precompiled GCC v3.3 crosscompiler for SH platform, where I have
> > a custom multithreaded OS. My development platform is win32 (Cygwin). I
> > want to port libstdc++ to work properly with my OS, but do not want to
> > compile gcc. (I do not use exceptions or rtti, so I suppose gcc
> > internally do not need to be aware of my OS.) Specifically, I only want
> > to use STL containers and algorithms, and nothing which need OS support
> > (e.g. IO streams, character types or locale).
> >
> > What I have to do?
> 
> Have you read the porting guide ?
> 
> http://gcc.gnu.org/onlinedocs/libstdc++/17_intro/porting.html

Yes, I did. Maybe it gives help for one who know how to build a
crosscompiler (moreover, only just a library from it) from scratch, but
it didn't help much to me.

This intro writes nothing about the configuration and building
libstdc++, and this info is what I need. I wrote a custom gthr.h file,
and want to build libstdc++-v3 with its defaults (generic files), as it
seems that it is OK for me. But I want to build with my existing
crosscompiler. This is not a common case what porting.html talks about.

More explanation is below:

The paper is a bit unclear what to do if I am content with the default
(generic) implementations (or will not use them), as this is the case
with every issues for me. About thread safety, the intro says:

"If you don't take any special action, the library will use stub
versions of these functions that are not thread-safe."

If stub versions mean using config/cpu/generic/atomicity.h, then this is
not the case, as it is a proper thread-safe implementation using gthr.h.
Anyway, looking into the source, it is evident that just implementing
atomicity.h itself (without a working bits/gthr.h) is not enough, but I
already wrote my gthr.h. If it is not the case, then what I have to do
to use the generic atomicity.h?

The paper mentions everywhere "configure.host", but there is no such
file in the source. Although, there is a configure.target, which seem to
be the proper file...

I am totally lost, so you are my only hope...

Thanks,
Ferenc