[patch] mkcshadow improvements
Anthony Williams
anthony_w.geo@yahoo.com
Tue May 16 02:57:00 GMT 2000
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
- ----- Original Message -----
From: Nathan Myers <ncm@zembu.com>
> Benjamin,
>
> Of course the _C_Swamp_ thing was a typo. I have sent a patch.
>
> It may be that we need to add some macros to the standard formula:
>
> _EXTRA_SWAMP_NESTING_CLOSE
> }
> }
> // stuff
> namespace _C_Swamp {
> extern "C" {
> _EXTRA_SWAMP_NESTING_OPEN
>
> where those macros are normally blank, but may handle an
> extra level of nesting. It may be hard to know when to turn
> those macros on and off.
>
> Anthony's idea of pre-including headers that are sub-included
> (in direct violation, by the way, of ISO C Standard requirements!)
> is interesting. The trick is to know which ones to put where,
> because which ones you need will vary with target system and
> version, and we like to minimize such per-target variations.
In what way does it violate the C standard requirements? Maybe I
didn't explain myself well enough. My thought was that in, say,
shadow/sys/feature_tests.h we put #include <stdio.h> because we know
that the real sys/feature_tests.h does #include <stdio.h> inside
extern "C". Thus only the same set of headers gets included as would
otherwise be the case (since headers are idempotent), but we have
control over where. The only problem is if the real header makes some
#defines before the #include which affect the included header.
This is indeed system-dependent, but so would be the
_EXTRA_SWAMP_NESTING_* macros, since they would vary from system to
system, and from header to header. This runs into problems with
headers that sub-include headers that sub-include headers, since the
_EXTRA_SWAMP_NESTING_* macros may vary between the two sub-includes,
so we need some kind of stacking. Arrgh!
That was why I suggested the #undef __cplusplus - if we can fool the
headers into thinking they're in C code without having any additional
side effects than missing extern "C"{} sections, then we're laughing.
However, it's the "additional side effects" bit that worries me.
Anthony
>
> Nathan Myers
> ncm@cantrip.org
>
> On Mon, May 15, 2000 at 11:38:22AM -0700, Benjamin Kosnik wrote:
> >
> > 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?)
> >
> > How did you generate these headers? And what version of solaris
> > are you using?
> >
> > 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.
> >
> > 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?
> >
> > -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?
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.1 for non-commercial use < http://www.pgp.com >
iQA/AwUBOSEa6pvw+P4cG5rVEQKXswCg/H65wkh19pMLK8njHlqLujVHdFsAn0vZ
HG0pfYirCbjoOWLVM9m367sH
=uPp0
-----END PGP SIGNATURE-----
__________________________________________________
Do You Yahoo!?
Talk to your friends online with Yahoo! Messenger.
http://im.yahoo.com
More information about the Libstdc++
mailing list