This is the mail archive of the libstdc++@sources.redhat.com mailing list for the libstdc++ project.


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

Re: wcout oddness


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


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