This is the mail archive of the
libstdc++@sources.redhat.com
mailing list for the libstdc++ project.
Re: wcout oddness
- To: Phil Edwards <pedwards at disaster dot jaj dot com>
- Subject: Re: wcout oddness
- From: Benjamin Kosnik <bkoz at redhat dot com>
- Date: Thu, 10 Aug 2000 09:54:19 -0700 (PDT)
- cc: libstdc++ at sources dot redhat dot com
> > And then I'll do the solaris port, all you long-suffering solaris
> > users....sorry about this.
>
> Enh, sometimes it happens. I for one will have boatloads of free time
> five days from now, but not before. If you can give us an idea of
> what needs to be done, we can start hacking on it. Is the generation
> of sys/cdefs.h the first step, or something else? (I've no clue about
> glibc.)
What will probably have to happen is that _G_config.h will have to be
ported to Solaris. So, I guess what you should do is start with this
approach. Copy the current linux/_G_config.h and start modifying it to
compile on solaris (you can probably use the generated _G_config.h that
libstdc++-v2/libio constructs as a reference point when things get hairy,
or at least as a point of useful comparison. There are a bunch of new
types and oddnesses, but hey.)
I would suggest getting Solaris <char> working first, and disabling
wchar_t support at the moment. Once you have this, post the patch.
Once you get this far, and have some kind of hacked _G_config up and
running, then the next step is how to do the configure bits. The libio
makefiles are hacked right now and there is not a clean break between
wchar_t/char as used to be, so this is one of the things that needs
cleanup.
After this, then Solaris 2.7<wchar_t> can be hacked on. So, the work
itself is at least two phases long...
---a side note:
I'm of two minds about the way the configure hacking should go:
1) have config/os and populate it with the same folders that we are
using a la ctype madness.
2) just have
libio/_G_config.h-linux
libio/_G_config.h-solaris
and then do sym-links to the build/libio/_G_config.h file a la
c++io.h/c++io.cc/c++threads.h
I'm currently more enthralled with approach #2, but I'm interested in
other opinions. I'm pretty sure that almost everybody agrees that the
current ctype system is not nearly elegant enough to last for much
longer...hopefully as part of the codecvt/ctype stuff that I'm doing now,
this stuff will be cleaned up as well.
And, if it looks like the changes to _G_config.h are not that big, we
could just go with one file, and use defines.
-benjamin