--enable-cshadow-headers remaining bits

[Nathan Myers]

On Thu, May 25, 2000 at 06:40:57AM -0700, Benjamin Kosnik wrote:
> 
> Parts that need clarification:
> 
> 1) Install bits not done. I leave this as an exercise to the person so
> quaintly referred to as the "make install" maintainer. Where are
> $bld/cshadow and $src/shadow to be installed? What exactly is
> $dest_dir?  
> 
> (from)
> [Note for maintainer of "make install": shadow/ dir should
> get copied to $dest_dir/include.]
> 
> We are definitely going to need a list of all cshadow and shadow 
> headers before the install bits can get hacked out.

For the case of a glibc target, the list of shadow/ headers is precisely 
those currently in shadow/.  I expect it may differ on other targets, 
and other targets might need additional files there...  (Note that we
hope to get rid of the non-standard shadow/sys/cdefs.h file.)

The list of cshadow/ headers is as generated by mkinclosure.

I don't know where is the right place to install the extra directories;
probably alongside include/g++-v3, i.e.

  include/
      cshadow/
      g++-v3/
      shadow/

or in 

  i686-pc-linux-gnu/include/
      cshadow/
      shadow/

Opinions welcome.

> 2) How is mkinclosure invoked? Have linux, need solaris. Specifically,
> how do we find the -G arguments in:
> 
> $(top_srcdir)/mkinclosure \
> "-I $(top_builddir)/../../gcc/include/ -I /usr/include -G machine/ansi.h"
> 
> vs.
> 
> -I ../../gcc/include/   -I /usr/include   -G machine/ansi.h  
> 
> It looks like this part might have to be tricked out per
> target_os. Ugh. What a drag. Phil, you might want to try and hack this
> for solaris if you get a chance. I think the -G options should be
> AC_SUBST(CSHADOW_EVIL_EVIL_DIE_DIE) or something. Now I'm starting to
> understand the pejorative naming...

The -G part certainly is a per-target-libc thing.  Maybe it could be 
partially automated by noting the result of one run, and passing the 
file names complained about as "-G" options on a second run.
 
The "-I" options should precisely match the list of "-I" C headers
looked up by the compiler on the target platform.  I.e.,

   $ v3/bin/gcc -v -c hello.cc
   ...
   #include <...> search starts here:
*  v3/lib/gcc-lib/i686-pc-linux-gnu/2.96/include
   v3/i686-pc-linux-gnu/include
   /home/ncm/Egcs/v3/include
*  /usr/include

At (late) configure time, the first perhaps corresponds to 
gcc/gcc/ginclude, although it's missing syslimits.h, limits.h,
and float.h.  I don't know where those come from.
 
> 3) Elaborate on "-D_ISOC9X_SOURCE": is this needed for linux, for
> solaris, for gcc, what? Does this need to be defined before
> "-I../../../src.egcs/libstdc++-v3/shadow -I/cshadow" includes are
> searched? Will the same thing be defined or will different things need
> to be defined on a per-platform basis?

It is needed under glibc because the shadow version of std::fprintf() 
calls _C_legacy::vfprintf() -- likewise, fscanf vs. vfscanf -- and 
the v*() functions are declared only for __USE_ISO_C99.  Alternative 
implementation advice welcome.
 
> 4) Should "-I../../../src.egcs/libstdc++-v3/shadow -I/cshadow"
> includes be searched when building the library itself? Assuming yes.
 
Right.
 
> 5) having problems with script:
> Making all in src
> make[2]: Entering directory `/mnt/hd/bliss/bld-x86-gcc-3/i586-pc-linux-gnu/libstdc++-v3/src'
> ../../../../src.egcs/libstdc++-v3/mkinclosure \
> "-I ../../../gcc/include/ -I /usr/include/ -G machine/ansi.h" | ../../../../src.egcs/libstdc++-v3/mkcshadow;
> Creating cshadow.
> Creating...
> ../../../../src.egcs/libstdc++-v3/mkinclosure: [: ==: binary operator expected
> ../../../../src.egcs/libstdc++-v3/mkinclosure: [: ==: binary operator expected
> [snip, ad infinium]

I think we saw this before, on your machine.  I wasn't able to
reproduce it.  Now that I look again, it appears that your bash
doesn't like "[ a == b ]" syntax.  The fix is probably just s/==/=/
in mkinclosure.  (According to the bash man page, == is preferred;
where did your version come from?)

Other stuff... Steven King has noted a problem where, under non-strict
modes, some "standard" C headers sub-include other standard headers in
blatant violation of standard requirements, and break generic_shadow.h.
We will be looking into it, and hope nothing really nasty must be done 
to work around it.  Pre-including the sub-included header in the shadow 
of the header that commits the error is our fall-back approach.  
Eliminating bits/generic_shadow.h and pasting the near-equivalent into 
each shadow header is another possibility.  I hope to find a better
way.

Anthony Williams has noticed that 'extern "C"' nesting doesn't work
right on Solarix.  In the best of all possible worlds the fix would
be to define macros for our use of it in our shadow headers (except 
in bits/generic_shadow.h), and define them null if the underlying
C headers do it by themselves.  Then we could eliminate the
horrifying shadow/sys/cdefs.h file.

Nathan Myers
ncm at cantrip dot org