[patch] mkcshadow improvements

Tue May 16 01:37:00 GMT 2000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

- - - ----- Original Message ----- 
From: Benjamin Kosnik <bkoz@cygnus.com>

> 
> Anthony:
> 
> Very interesting. Can I please move this to the libstdc++ list so
> that it gets archived? (Or can you cc the list if you respond to me
> please?)  

CC'ed - I just didn't want to put a tarball in everyone's inbox.

> How did you generate these headers? And what version of solaris are
> you using?  

I generated them manually for the ones with any content, using my
draft copy of the standard for the list of requirements. The ones
that just do namespace _C_Swamp{#include_next }, with the big GNU
copyright string were re-generated by Nathan's mkcshadow script (when
I had found it :), having previously been a cut-and-paste job.

Sparc-solaris-2.7

> Is there anyway you can give me a 'cvs diff -cp' of the include
> files, since there are so many files? I'm not quite sure how each
> individual header changed, and I'd like to be able to scope this
> via a diff.  

I don't have CVS, but here's the output from "diff -r" against the
installed include directory (attached)

> Also, you and Nathan should work out the _C_swamp naming convention
> thing. Nathan, this name seems kind of silly, perhaps you could
> come up with something that is a bit more meaningful?  

How about just _C_, seeing its purpose is to enclose the C headers
from the host environment, or is that reserved for something else?

> 
> -benjamin
> 
> 
> 
> On Mon, 15 May 2000, Anthony Williams wrote:
> 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > Benjamin,
> > 
> > Attached is a tarball of the complete set of headers for my copy
> > of libstdc++, including all the standard C++ headers (iostream,
> > algorithm etc). This is because I ran against problems if they
> > weren't in the same directory (sub includes picked the wrong copy
> > of the shadowed headers)  
> > 
> > I currently cannot get the library to build, using these headers,
> > since some of the Solaris headers sub-include things like
> > stdio.h, inside extern "C" blocks, so the namespaces aren't at
> > global scope, as there aren't enough closing brackets to break
> > out of the top-level _C_Swamp namespace. ARGHHHH! Anyway, looking
> > at the headers, it appears that this only happens for C++ code,
> > due to a #ifdef _cplusplus, or somesuch, so I wonder if it would
> > break anything to #undef this (a bit naughty really, I know ;)
> > Alternatively, we could sub-include the same headers in the
> > shadow headers, so they are included in the correct scope, and
> > the include-guards will mask the second include. I haven't
> > checked how many times this occurs. Anyway, with this set of
> > headers, the only errors in the test suite occur where the test
> > suite assumes the symbol is at global scope, when it is now in
> > std::, or where it links against streambuf, since fpos_t is now
> > std::fpos_t, so the template names are different (hence the need
> > to rebuild the library, which currently isn't working), or where
> > there was already an error (21_strings, and a couple of others)  
> > 
> > Note that Nathan's mkcshadow program generates incorrect headers,
> > since the two _C_Swamp references don't match (one is _C_Swamp,
> > the other is _C_Swamp_ ), so I patched that first.  
> > 
> > Also required is a patch to the "new" header for gcc
> > ($PREFIX/lib/gcc-lib/sparc-solaris-2.7/2.96/include/new), so that
> > it uses std::size_t, which must be defined if not available, so
> > gcc will build. (diff below)  
> > 
> > Anthony
> > 
> > diff ~awilliam/include/fixinc/new
> > $PREFIX/lib/gcc-lib/sparc-solaris-2.7/2.96/include/new
> > 15,18d14
> > < #ifndef _CPP_SIZE_T
> > <     typedef ::size_t size_t;
> > < #endif
> > < 
> > 32,33c28,29
> > < void *operator new (std::size_t) throw (std::bad_alloc);
> > < void *operator new[] (std::size_t) throw (std::bad_alloc);
> > - ---
> > > void *operator new (size_t) throw (std::bad_alloc);
> > > void *operator new[] (size_t) throw (std::bad_alloc);
> > 36,37c32,33
> > < void *operator new (std::size_t, const std::nothrow_t&)
> > throw(); < void *operator new[] (std::size_t, const
> > std::nothrow_t&) throw(); - --- 
> > > void *operator new (size_t, const std::nothrow_t&) throw();
> > > void *operator new[] (size_t, const std::nothrow_t&) throw();
> > 42,43c38,39
> > < inline void *operator new(std::size_t, void *place) throw() {
> > return place; }
> > < inline void *operator new[](std::size_t, void *place) throw() {
> > return place; }
> > - ---
> > > inline void *operator new(size_t, void *place) throw() { return
> > > place; } inline void *operator new[](size_t, void *place)
> > > throw() { return place; }   
> > 
> > - ----- Original Message ----- 
> > From: Benjamin Kosnik <bkoz@cygnus.com>
> > To: <libstdc++@sourceware.cygnus.com>
> > Sent: 15 May 2000 07:30
> > Subject: Re: [patch] mkcshadow improvements
> > 
> > 
> > > 
> > > Ok Nathan, I checked this in. I'm still interested in seeing
> > > the state of Anthony's work on solaris. Anthony, can you post
> > > what you have, even if it's a tarball?    
> > > 
> > > >Hmm, I can't agree.  The "inclosure" script doesn't actually 
> > > 
> > > script == mk notation
> > > 
> > > >make anything, it just generates a list of header names to
> > > >pipe into mkcshadow.  In fact it probably could be integrated
> > > >into  mkcshadow once we're confident that it's right.  Maybe,
> > > >though, it would be better to save its output to a file in the
> > > >build directory, to make it easier to audit what it's up to. 
> > > 
> > > If it can be integrated, then do it and this issue will be
> > > moot.  My preference is to save output to a file so that it's
> > > easier to see what all thse trickster scripts actually do.    
> > > 
> > > >Attached below is an improvement to mkcshadow, so it creates 
> > > >cshadow/* in the build directory rather than the source
> > > >directory 
> > > 
> > > Yep. You shouldn't write into the source directory. This is
> > > easy to do in autoconf...    
> > > 
> > > >  ../../../gcc/libstdc++-v3/inclosure \
> > > >    -I ../../../v3/lib/gcc-lib/i686-pc-linux-gnu/2.96/include/
> > > > \ 
> > > >    -I /usr/include \
> > > >    -G machine/ansi.h \
> > > >   | ../../../gcc/libstdc++-v3/mkcshadow 
> > > 
> > > Okay. Let me try to decipher what you've done:
> > > 
> > > GCC_EXEC_PREFIX/include
> > > /usr/include
> > > 
> > > but then what's the machine/ansi.h stuff, and how would this
> > > translate to solaris, for instance?  
> > > 
> > > >The appropriate "-I" arguments must be discovered by
> > > >configure, and  the -G argument(s) depend on the target build
> > > >environment.  
> > > 
> > > Can you explain how configure is to discover them? At least
> > > what it should look for?  
> > > 
> > - -benjamin
> > 
> > -----BEGIN PGP SIGNATURE-----
> > Version: PGPfreeware 6.5.1 for non-commercial use
> > < http://www.pgp.com >  
> > 
> > iQA/AwUBOR+7vpvw+P4cG5rVEQL58QCfcNb5hSCE9LMW+WpfNUQIn7bKC08AoOVE
> > 95JnyHYJUdb56SxpkMfzLvDJ
> > =DRyj
> > -----END PGP SIGNATURE-----
> > 
> > 

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.1 for non-commercial use < http://www.pgp.com >

iQA/AwUBOSEIZZvw+P4cG5rVEQJZcgCfWkSQ2Geo/9mVYtyePktBAz6wXVwAnRWt
+CiMujHDEET4Bz8pZLJktE0f
=l2+T
-----END PGP SIGNATURE-----