Implications of tighter integration of libg++

Implications of tighter integration of libg++

[Loren J. Rittle]

Under EGCS, there is now tighter integration between g++ and the
required standard C++ libraries, in that they are now distributed and
configured together.

Should we assume that this tighter integration will continue?  Or is
this just a short-term situation to aid current development?

The reason I ask is that

./configure --with-gxx-include-dir\=\'\$\{libsubdir\}/include/g++\'

invoked at the top-level doesn't work as expected.  Granted, the
top-level and library configuration programs don't currently
understand ${libsubdir} so I shouldn't have expected this to work.

It is desirable to place libraries compiled against and dependent upon
a given version of g++, and their related header files, into the
compiler's lib and include directory.  Thus, I actually believe that
something akin to the above should be the default.  Someone else
believed this at one time given the comments in gcc/Makefile.in:

> # The reason we use $(libdir)/g++-include rather than using libsubdir
> # is for compatibility with the current version of libg++.

Given the current state of integration, now might be a golden time to
break this ``compatibility''.  It is always annoying to have
accidentally wiped out an old working g++/libg++ configuration when a
new version of the compiler is installed.

The included patches are not perfect (i.e. they only work for g++ and
only when the default g++ header location has not been overridden with
--with-gxx-include-dir).  However, they are no worse than the current
state of affairs since --with-gxx-include-dir doesn't currently
interplay with the libraries' build process.  If this patch (or some
improvement upon it) is deemed acceptable, then perhaps
--with-gxx-include-dir should be revoked as well.

A better patch would enhance gcc/g++ to add new --print-* switches to
allow tools that build system libraries to find the exact locations
where gcc/g++ wants library and headers to be installed (these
locations might be different --- and it might be better for g++ to
supply the entire destination to the headers instead of the current
model used --- see the patch).

This patch also gets rid of $(old_gxx_include_dir) from
gcc/Makefile.in and OLD_GPLUSPLUS_INCLUDE_DIR from gcc/cccp.c and
gcc/cpplib.c since it can't be right to ever want these old versions
of libraries under the tightly integrated model.

Example of paths (with default ./configure):
$ gcc --print-file-name\=include/g++
/usr/local/lib/gcc-lib/sparc-sun-solaris2.6/egcs-2.90.18/include/g++
$ gcc --print-file-name\=libstdc++.a
/usr/local/lib/gcc-lib/sparc-sun-solaris2.6/egcs-2.90.18/libstdc++.a

As new versions of tools are installed, old installations will
continue to operate as before since there support libraries are not
overwritten.

[Since this patch only changes 8 lines of code/shell script and
 removes another 8 lines of code/shell script, I believe it too minor
 to file copyright paperwork.  I and Motorola hereby disclaim all
 rights to this patch.  It is released into the public domain.]

Regards,
Loren
-- 
Loren J. Rittle (rittle@comm.mot.com)	PGP KeyIDs: 1024/B98B3249 2048/ADCE34A5
Systems Technology Research (IL02/2240)	FP1024:6810D8AB3029874DD7065BC52067EAFD
Motorola, Inc.				FP2048:FDC0292446937F2A240BC07D42763672
(847) 576-7794				Call for verification of fingerprints.

diff -Nrc3p -x *.info* /tmp/egcs-971122/gcc/Makefile.in egcs-971122/gcc/Makefile.in
*** /tmp/egcs-971122/gcc/Makefile.in	Mon Nov 24 17:43:59 1997
--- egcs-971122/gcc/Makefile.in	Mon Nov 24 17:32:20 1997
*************** libdir = @libdir@
*** 218,225 ****
  libsubdir = $(libdir)/gcc-lib/$(target_alias)/$(version)
  # Directory in which the compiler finds g++ includes.
  gxx_include_dir= @gxx_include_dir@
- # Directory in which the old g++ header files may be found.
- old_gxx_include_dir= $(libdir)/g++-include
  # Directory to search for site-specific includes.
  includedir = $(local_prefix)/include
  # assertdir is overridden in cross-make.
--- 218,223 ----
*************** $(srcdir)/cexp.c: $(srcdir)/cexp.y
*** 1731,1742 ****
  	cd $(srcdir); $(BISON) -o cexp.c cexp.y
  
  cccp.o: cccp.c $(CONFIG_H) pcp.h version.c config.status
- # The reason we use $(libdir)/g++-include rather than using libsubdir
- # is for compatibility with the current version of libg++.
  	$(CC) $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \
  	  -DGCC_INCLUDE_DIR=\"$(libsubdir)/include\" \
  	  -DGPLUSPLUS_INCLUDE_DIR=\"$(gxx_include_dir)\" \
- 	  -DOLD_GPLUSPLUS_INCLUDE_DIR=\"$(old_gxx_include_dir)\" \
  	  -DLOCAL_INCLUDE_DIR=\"$(includedir)\" \
  	  -DCROSS_INCLUDE_DIR=\"$(libsubdir)/sys-include\" \
  	  -DTOOL_INCLUDE_DIR=\"$(tooldir)/include\" \
--- 1729,1737 ----
*************** cpplib.o: cpplib.c $(CONFIG_H) cpplib.h 
*** 1753,1759 ****
  	$(CC) $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \
  	  -DGCC_INCLUDE_DIR=\"$(libsubdir)/include\" \
  	  -DGPLUSPLUS_INCLUDE_DIR=\"$(gxx_include_dir)\" \
- 	  -DOLD_GPLUSPLUS_INCLUDE_DIR=\"$(old_gxx_include_dir)\" \
  	  -DLOCAL_INCLUDE_DIR=\"$(includedir)\" \
  	  -DCROSS_INCLUDE_DIR=\"$(libsubdir)/sys-include\" \
  	  -DTOOL_INCLUDE_DIR=\"$(tooldir)/include\" \
--- 1748,1753 ----
diff -Nrc3p -x *.info* /tmp/egcs-971122/gcc/cccp.c egcs-971122/gcc/cccp.c
*** /tmp/egcs-971122/gcc/cccp.c	Wed Oct  1 01:22:46 1997
--- egcs-971122/gcc/cccp.c	Fri Nov 21 04:58:15 1997
*************** static struct default_include {
*** 590,596 ****
    = {
      /* Pick up GNU C++ specific include files.  */
      { GPLUSPLUS_INCLUDE_DIR, 1, 1 },
-     { OLD_GPLUSPLUS_INCLUDE_DIR, 1, 1 },
  #ifdef CROSS_COMPILE
      /* This is the dir for fixincludes.  Put it just before
         the files that we fix.  */
--- 590,595 ----
diff -Nrc3p -x *.info* /tmp/egcs-971122/gcc/configure egcs-971122/gcc/configure
*** /tmp/egcs-971122/gcc/configure	Mon Nov 24 17:44:00 1997
--- egcs-971122/gcc/configure	Mon Nov 24 17:36:12 1997
*************** if test "${with_gxx_include_dir+set}" = 
*** 610,622 ****
    withval="$with_gxx_include_dir"
    gxx_include_dir=$with_gxx_include_dir
  else
!   gxx_include_dir='${prefix}/include/g++'
  fi
  
  
  # Default g++ header file directory if it is empty
  if [ x$gxx_include_dir = x ]; then
! 	gxx_include_dir='${prefix}/include/g++'
  fi
  
  # Enable use of cpplib for C.
--- 610,622 ----
    withval="$with_gxx_include_dir"
    gxx_include_dir=$with_gxx_include_dir
  else
!   gxx_include_dir='${libsubdir}/include/g++'
  fi
  
  
  # Default g++ header file directory if it is empty
  if [ x$gxx_include_dir = x ]; then
! 	gxx_include_dir='${libsubdir}/include/g++'
  fi
  
  # Enable use of cpplib for C.
diff -Nrc3p -x *.info* /tmp/egcs-971122/gcc/configure.in egcs-971122/gcc/configure.in
*** /tmp/egcs-971122/gcc/configure.in	Mon Nov 24 17:44:00 1997
--- egcs-971122/gcc/configure.in	Mon Nov 24 17:35:26 1997
*************** AC_ARG_WITH(gxx-include-dir,
*** 71,81 ****
  [  --with-gxx-include-dir=DIR
                            specifies directory to put g++ header files.],
  gxx_include_dir=$with_gxx_include_dir,
! gxx_include_dir='${prefix}/include/g++')
  
  # Default g++ header file directory if it is empty
  if [[ x$gxx_include_dir = x ]]; then
! 	gxx_include_dir='${prefix}/include/g++'
  fi
  
  # Enable use of cpplib for C.
--- 71,81 ----
  [  --with-gxx-include-dir=DIR
                            specifies directory to put g++ header files.],
  gxx_include_dir=$with_gxx_include_dir,
! gxx_include_dir='${libsubdir}/include/g++')
  
  # Default g++ header file directory if it is empty
  if [[ x$gxx_include_dir = x ]]; then
! 	gxx_include_dir='${libsubdir}/include/g++'
  fi
  
  # Enable use of cpplib for C.
diff -Nrc3p -x *.info* /tmp/egcs-971122/gcc/cpplib.c egcs-971122/gcc/cpplib.c
*** /tmp/egcs-971122/gcc/cpplib.c	Thu Sep 11 17:51:33 1997
--- egcs-971122/gcc/cpplib.c	Fri Nov 21 05:00:13 1997
*************** static struct default_include {
*** 363,369 ****
    = {
      /* Pick up GNU C++ specific include files.  */
      { GPLUSPLUS_INCLUDE_DIR, 1, 1 },
-     { OLD_GPLUSPLUS_INCLUDE_DIR, 1, 1 },
  #ifdef CROSS_COMPILE
      /* This is the dir for fixincludes.  Put it just before
         the files that we fix.  */
--- 363,368 ----
diff -Nrc3p -x *.info* /tmp/egcs-971122/libiberty/Makefile.in egcs-971122/libiberty/Makefile.in
*** /tmp/egcs-971122/libiberty/Makefile.in	Wed Oct 29 00:39:04 1997
--- egcs-971122/libiberty/Makefile.in	Mon Nov 24 16:07:27 1997
*************** prefix = /usr/local
*** 32,38 ****
  
  exec_prefix = $(prefix)
  bindir = $(exec_prefix)/bin
! libdir = $(exec_prefix)/lib
  
  datadir = $(prefix)/share
  
--- 32,38 ----
  
  exec_prefix = $(prefix)
  bindir = $(exec_prefix)/bin
! libdir = `$(CXX) --print-file-name\=`
  
  datadir = $(prefix)/share
  
*************** man7dir = $(mandir)/man7
*** 47,53 ****
  man8dir = $(mandir)/man8
  man9dir = $(mandir)/man9
  infodir = $(prefix)/info
! includedir = $(prefix)/include
  
  SHELL = /bin/sh
  
--- 47,53 ----
  man8dir = $(mandir)/man8
  man9dir = $(mandir)/man9
  infodir = $(prefix)/info
! includedir = `$(CXX) --print-file-name\=`include
  
  SHELL = /bin/sh
  
diff -Nrc3p -x *.info* /tmp/egcs-971122/libio/config.shared egcs-971122/libio/config.shared
*** /tmp/egcs-971122/libio/config.shared	Fri Sep 26 23:06:54 1997
--- egcs-971122/libio/config.shared	Mon Nov 24 16:05:12 1997
*************** echo "prefix = ${prefix-/usr/local}"
*** 72,78 ****
  echo "exec_prefix = ${exec_prefix-'${prefix}'}"
  
  echo 'bindir = $(exec_prefix)/bin'
! echo 'libdir = $(exec_prefix)/lib'
  
  echo 'datadir = $(prefix)/lib'
  echo 'mandir = $(prefix)/man'
--- 72,78 ----
  echo "exec_prefix = ${exec_prefix-'${prefix}'}"
  
  echo 'bindir = $(exec_prefix)/bin'
! echo 'libdir = `$(CXX) --print-file-name\=`'
  
  echo 'datadir = $(prefix)/lib'
  echo 'mandir = $(prefix)/man'
*************** echo 'man8dir = $(mandir)/man8'
*** 87,93 ****
  echo 'man9dir = $(mandir)/man9'
  
  echo 'infodir = $(prefix)/info'
! echo 'includedir = $(prefix)/include'
  echo 'gxx_includedir = $(includedir)/g++'
  echo 'docdir = $(datadir)/doc'
  echo ''
--- 87,93 ----
  echo 'man9dir = $(mandir)/man9'
  
  echo 'infodir = $(prefix)/info'
! echo 'includedir = `$(CXX) --print-file-name\=`include'
  echo 'gxx_includedir = $(includedir)/g++'
  echo 'docdir = $(datadir)/doc'
  echo ''

Re: Implications of tighter integration of libg++

[Manfred.Hollstein]

On Mon, 24 November 1997, 18:40:23, rittle@supra.rsch.comm.mot.com wrote:

    Under EGCS, there is now tighter integration between g++ and the
    required standard C++ libraries, in that they are now distributed and
    configured together.
    
    Should we assume that this tighter integration will continue?  Or is
    this just a short-term situation to aid current development?
    
    [lots of stuff deleted]

I agree completely; under < http://www.cygnus.com/ml/egcs-bugs/1997-Oct/0197.html >
you  can see a patch  I  posted to achieve  this  at least partially.  Your patch
differs mostly  in installing the  libraries in ${libsubdir}  than at the default
locations (btw,  I'm doing this from my  install script  after `make install' has
finished :-).

-- 
 Manfred Hollstein                               Alcatel, Dept. US/EC4
 < mailto:Manfred.Hollstein@ks.sel.alcatel.de >    Lorenzstrasse 10
                                                 70435 Stuttgart
 Public PGP key on request                       Germany

Re: Implications of tighter integration of libg++

[Jeffrey A Law]

  In message <199711250040.SAA09460@supra.rsch.comm.mot.com>you write:
  > Under EGCS, there is now tighter integration between g++ and the
  > required standard C++ libraries, in that they are now distributed and
  > configured together.
  > 
  > Should we assume that this tighter integration will continue?  Or is
  > this just a short-term situation to aid current development?
We expect the tighter integration to continue indefinitely.

[ ... ]
  > It is desirable to place libraries compiled against and dependent upon
  > a given version of g++, and their related header files, into the
  > compiler's lib and include directory.  Thus, I actually believe that
  > something akin to the above should be the default.  Someone else
  > believed this at one time given the comments in gcc/Makefile.in:
With the stabilizaton of the C++ language and its associated runtime libraries
I wonder if this will be all that useful.

I kinda get the feeling that we'll start seeing releases that are compatable
at both the header file level and at the link level in the near future.

Just my opinions -- the g++ folks might have different ideas about this
whole area.

jeff

Re: Implications of tighter integration of libg++

[Martin von Loewis]

> Just my opinions -- the g++ folks might have different ideas about this
> whole area.

I think about namespaces from time to time. It seems that proper
namespace support will quite dramatically change the library
interface. Everything in libstdc++ is supposed to live in namespace
std{}; and names in there should be different from application-defined
names. So as a result, every name will be qualified with Q23std in the
long run.

I'm not sure how the .h header files of libstdc++ should be handled;
the standard allows to use them for backwards compatibility. Perhaps
g++ will still need to special-case namespace std, and generate the
appropriate aliases.

What do you think?

Martin

Re: Implications of tighter integration of libg++

[Jason Merrill]

>>>>> Jeffrey A Law <law@cygnus.com> writes:

>> It is desirable to place libraries compiled against and dependent upon
>> a given version of g++, and their related header files, into the
>> compiler's lib and include directory.  Thus, I actually believe that
>> something akin to the above should be the default.  Someone else
>> believed this at one time given the comments in gcc/Makefile.in:

> With the stabilizaton of the C++ language and its associated runtime
> libraries I wonder if this will be all that useful.

> I kinda get the feeling that we'll start seeing releases that are
> compatable at both the header file level and at the link level in the
> near future.

Perhaps, but they will be different all the same, and it makes sense to use
versions that have been tested together.

On the other hand, using a different --prefix for different releases will
accomplish the same result.

Jason

Re: Implications of tighter integration of libg++

[Joe Buck]

>   > It is desirable to place libraries compiled against and dependent upon
>   > a given version of g++, and their related header files, into the
>   > compiler's lib and include directory.

Yes, but once we have complete standards conformance, we should get to the
point where libstdc++ always has the exact same API, so this kind of
dependency doesn't really exist.  I think that the compiler-specific
lib directory really makes sense only for static libraries, not shared
libraries.

Re: Implications of tighter integration of libg++

[Jeffrey A Law]

  In message < u9k9b4valw.fsf@yorick.cygnus.com >you write:
  > > I kinda get the feeling that we'll start seeing releases that are
  > > compatable at both the header file level and at the link level in the
  > > near future.
  > 
  > Perhaps, but they will be different all the same, and it makes sense to use
  > versions that have been tested together.
  > 
  > On the other hand, using a different --prefix for different releases will
  > accomplish the same result.
So would you prefer the status quo for headers and libs, or would you
prefer to see them pushed down into libsubdir?

jeff

Re: Implications of tighter integration of libg++

[Jason Merrill]

>>>>> Jeffrey A Law <law@cygnus.com> writes:

> So would you prefer the status quo for headers and libs, or would you
> prefer to see them pushed down into libsubdir?

libsubdir, I suppose.

Jason

Re: Implications of tighter integration of libg++

[H.J. Lu]

> 
> 
> >   > It is desirable to place libraries compiled against and dependent upon
> >   > a given version of g++, and their related header files, into the
> >   > compiler's lib and include directory.
> 
> Yes, but once we have complete standards conformance, we should get to the
> point where libstdc++ always has the exact same API, so this kind of

Did you mean ABI or API? With the old g++, API might be the same. But
ABI changed. I was talking about vtable and name mangling.

> dependency doesn't really exist.  I think that the compiler-specific
> lib directory really makes sense only for static libraries, not shared
> libraries.
> 
> 
> 


-- 
H.J. Lu (hjl@gnu.org)

Re: Implications of tighter integration of libg++

[Joe Buck]

> I'm not sure how the .h header files of libstdc++ should be handled;
> the standard allows to use them for backwards compatibility. Perhaps
> g++ will still need to special-case namespace std, and generate the
> appropriate aliases.

The goal of any such scheme is, as much as possible, to keep old programs
working.

One possibility is that iostream.h include <iostream>, followed by using
directives that import the names declared in <iostream>.  We should *not*
say "using namespace std;" as that imports all names.  Rather, just
things like

using std::istream;
using std::ostream;
using std::cin;
using std::cout;
using std::cerr;

etc.  I wouldn't advise 'using' for new facilities that didn't exist in
old libstdc++ versions (wide streams).

Then there's the problem that 'class ostream;' is now wrong.

Re: Implications of tighter integration of libg++

[Fred Fish]

> > So would you prefer the status quo for headers and libs, or would you
> > prefer to see them pushed down into libsubdir?
> 
> libsubdir, I suppose.

The below patch is what we use in Geek Gadgets to get gcc to look under
libsubdir for g++ include files, ahead of the normal include dir:

	* Makefile.in (cccp.o): Define GPLUSPLUS_INCLUDE_DIR_SPECIFIC
	when compiling.
	* cccp.c (include_defaults_array): Add GPLUSPLUS_INCLUDE_DIR_SPECIFIC
	ahead of GPLUSPLUS_INCLUDE_DIR entry.
	* cpplib.c (include_defaults_array): Add GPLUSPLUS_INCLUDE_DIR_SPECIFIC
	ahead of GPLUSPLUS_INCLUDE_DIR entry.

*** Makefile.in	1997/11/24 04:15:29	1.1.1.8
--- Makefile.in	1998/01/21 17:20:42	1.13
***************
*** 1735,1740 ****
--- 1764,1770 ----
  # is for compatibility with the current version of libg++.
  	$(CC) $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \
  	  -DGCC_INCLUDE_DIR=\"$(libsubdir)/include\" \
+ 	  -DGPLUSPLUS_INCLUDE_DIR_SPECIFIC=\"$(libsubdir)/include/g++\" \
  	  -DGPLUSPLUS_INCLUDE_DIR=\"$(gxx_include_dir)\" \
  	  -DOLD_GPLUSPLUS_INCLUDE_DIR=\"$(old_gxx_include_dir)\" \
  	  -DLOCAL_INCLUDE_DIR=\"$(includedir)\" \
***************
*** 1752,1757 ****
--- 1782,1788 ----
  cpplib.o: cpplib.c $(CONFIG_H) cpplib.h cpphash.h config.status
  	$(CC) $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \
  	  -DGCC_INCLUDE_DIR=\"$(libsubdir)/include\" \
+ 	  -DGPLUSPLUS_INCLUDE_DIR_SPECIFIC=\"$(libsubdir)/include/g++\" \
  	  -DGPLUSPLUS_INCLUDE_DIR=\"$(gxx_include_dir)\" \
  	  -DOLD_GPLUSPLUS_INCLUDE_DIR=\"$(old_gxx_include_dir)\" \
  	  -DLOCAL_INCLUDE_DIR=\"$(includedir)\" \
***************
*** 1789,1794 ****
--- 1820,1826 ----
  stamp-proto: protoize.c getopt.h $(CONFIG_H)
  	$(CC) -c $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \
            -DGCC_INCLUDE_DIR=\"$(libsubdir)/include\" \
+ 	  -DGPLUSPLUS_INCLUDE_DIR_SPECIFIC=\"$(libsubdir)/include/g++\" \
  	  -DGPLUSPLUS_INCLUDE_DIR=\"$(gxx_include_dir)\" \
            -DCROSS_INCLUDE_DIR=\"$(libsubdir)/sys-include\" \
  	  -DTOOL_INCLUDE_DIR=\"$(tooldir)/include\" \
***************
*** 1798,1803 ****
--- 1830,1836 ----
  	mv protoize$(objext) unprotoize$(objext)
  	$(CC) -c $(ALL_CFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \
            -DGCC_INCLUDE_DIR=\"$(libsubdir)/include\" \
+ 	  -DGPLUSPLUS_INCLUDE_DIR_SPECIFIC=\"$(libsubdir)/include/g++\" \
  	  -DGPLUSPLUS_INCLUDE_DIR=\"$(gxx_include_dir)\" \
            -DCROSS_INCLUDE_DIR=\"$(libsubdir)/sys-include\" \
  	  -DTOOL_INCLUDE_DIR=\"$(tooldir)/include\" \
***************
*** 1828,1833 ****
--- 1861,1867 ----
  	./protoize -N -B ./ -x getopt.h -c "-B./ -Wall -Wwrite-strings \
  	  $(CFLAGS) $(INCLUDES) \
  	  -DGCC_INCLUDE_DIR=0 \
+ 	  -DGPLUSPLUS_INCLUDE_DIR_SPECIFIC=0 \
  	  -DGPLUSPLUS_INCLUDE_DIR=0 \
  	  -DCROSS_INCLUDE_DIR=0 \
  	  -DTOOL_INCLUDE_DIR=0 \
***************
*** 1838,1843 ****
--- 1872,1878 ----
  	./unprotoize -N -x getopt.h -c "-B./ -Wall -Wwrite-strings \
  	  $(CFLAGS) $(INCLUDES) \
  	  -DGCC_INCLUDE_DIR=0 \
+ 	  -DGPLUSPLUS_INCLUDE_DIR_SPECIFIC=0 \
  	  -DGPLUSPLUS_INCLUDE_DIR=0 \
  	  -DCROSS_INCLUDE_DIR=0 \
  	  -DTOOL_INCLUDE_DIR=0 \
*** cccp.c	1997/10/10 21:53:17	1.1.1.2
--- cccp.c	1998/01/21 18:12:27	1.2
***************
*** 588,593 ****
--- 593,600 ----
    = INCLUDE_DEFAULTS;
  #else
    = {
+     /* Pick up GNU C++ specific include files for specific gcc release.  */
+     { GPLUSPLUS_INCLUDE_DIR_SPECIFIC, 1, 1 },
      /* Pick up GNU C++ specific include files.  */
      { GPLUSPLUS_INCLUDE_DIR, 1, 1 },
      { OLD_GPLUSPLUS_INCLUDE_DIR, 1, 1 },
*** cpplib.c	1997/09/18 23:24:03	1.1.1.2
--- cpplib.c	1998/01/21 18:24:39	1.3
***************
*** 361,366 ****
--- 366,373 ----
    = INCLUDE_DEFAULTS;
  #else
    = {
+     /* Pick up GNU C++ specific include files for specific gcc release. */
+     { GPLUSPLUS_INCLUDE_DIR_SPECIFIC, 1, 1},
      /* Pick up GNU C++ specific include files.  */
      { GPLUSPLUS_INCLUDE_DIR, 1, 1 },
      { OLD_GPLUSPLUS_INCLUDE_DIR, 1, 1 },

Re: Implications of tighter integration of libg++

[Martin von Loewis]

> say "using namespace std;" as that imports all names.  Rather, just
> things like
> 
> using std::istream;
> using std::ostream;
> using std::cin;
> using std::cout;
> using std::cerr;

This does not solve the problem I'm talking about. With that scheme,
and the implementation of namespace I have in mind, names would still
come out as Q23std7istream, rather than 7istream as they do now. This
is because the compiler would always resolve names to the place where
they are actually introduced, regardless of any using and typedef
magic applied.

So, even if old sources would still compile, old objects would not
link anymore. This is especially bad in presence of shared libraries
which have to accomodate both sets of header files.

Therefore, I think there is some value to the proposal of installing
libg++ in the compiler-specific directories.

Regards,
Martin

Re: Implications of tighter integration of libg++

[H.J. Lu]

> 
> > say "using namespace std;" as that imports all names.  Rather, just
> > things like
> > 
> > using std::istream;
> > using std::ostream;
> > using std::cin;
> > using std::cout;
> > using std::cerr;
> 
> This does not solve the problem I'm talking about. With that scheme,
> and the implementation of namespace I have in mind, names would still
> come out as Q23std7istream, rather than 7istream as they do now. This
> is because the compiler would always resolve names to the place where
> they are actually introduced, regardless of any using and typedef
> magic applied.
> 
> So, even if old sources would still compile, old objects would not
> link anymore. This is especially bad in presence of shared libraries
> which have to accomodate both sets of header files.

That can be done via symbol alias.

> 
> Therefore, I think there is some value to the proposal of installing
> libg++ in the compiler-specific directories.
> 

I think that is no good. It is the same as make libgcc shared.


-- 
H.J. Lu (hjl@gnu.org)

Re: Implications of tighter integration of libg++

[Joe Buck]

I wrote:
> > say "using namespace std;" as that imports all names.  Rather, just
> > things like
> > 
> > using std::istream;
> > using std::ostream;
> > using std::cin;
> > using std::cout;
> > using std::cerr;

Martin von Loewis writes:
> This does not solve the problem I'm talking about. With that scheme,
> and the implementation of namespace I have in mind, names would still
> come out as Q23std7istream, rather than 7istream as they do now. This
> is because the compiler would always resolve names to the place where
> they are actually introduced, regardless of any using and typedef
> magic applied.
> 
> So, even if old sources would still compile, old objects would not
> link anymore. This is especially bad in presence of shared libraries
> which have to accomodate both sets of header files.

If the only issue were that library functions and data definitions move
into std, we could solve it in the linker: GNU ld would get a list of
names to be remapped, and it would make old programs link by means of
name remapping for identifiers that would otherwise be undefined.

Unfortunately, iostreams needs to get a much bigger rewrite: not only
do istream and ostream move into std, but they are really
basic_istream<char> and basic_ostream<char>.  A number of access
functions change as well.

Even so, perhaps a backward compatibility layer could be written.  But it
might be easier just to ship two libstdc++ versions with different major
version numbers than to try to figure out how to make one library do.  The
whole reason for using the std namespace is so that users are freed up to
use the hundreds of names the standard library takes away.  Any scheme
that tries to preserve backward compatibility will also pollute the
namespace (preventing users from using certain identifier names), meaning
that we won't have a conforming compiler.

For that reason I think that the solution to binary compatibility is to
just bump the major version number on the shared library.  Users who must
run old binaries will need the old shared library, but the two versions
can co-exist on the same system.

Re: Implications of tighter integration of libg++

[John A. Tamplin]

On Mon, 9 Feb 1998, Joe Buck wrote:

> Even so, perhaps a backward compatibility layer could be written.  But it
> might be easier just to ship two libstdc++ versions with different major
> version numbers than to try to figure out how to make one library do.  The
> whole reason for using the std namespace is so that users are freed up to
> use the hundreds of names the standard library takes away.  Any scheme
> that tries to preserve backward compatibility will also pollute the
> namespace (preventing users from using certain identifier names), meaning
> that we won't have a conforming compiler.

Why couldn't you just have the compatibility layer in a separate library?
That way those symbols would only be used if it were explicitly added to
the link command.  For those sites that didn't care about using the 
previously reserved symbols, it could be automatically linked or even be
included as a separate object in the standard library.

John Tamplin					Traveller Information Services
jat@Traveller.COM				2104 West Ferry Way
205/883-4233x7007				Huntsville, AL 35801

Re: Implications of tighter integration of libg++

[Joe Buck]

[ changes in libstdc++ interface ]

> > Even so, perhaps a backward compatibility layer could be written.  But it
> > might be easier just to ship two libstdc++ versions with different major
> > version numbers than to try to figure out how to make one library do.

> Why couldn't you just have the compatibility layer in a separate library?

Well, that's what two libraries give you.  Ah, but you want a small
compatibility layer rather than an entirely separate library.  This is
possible, but in the absence of a volunteer to do the job it isn't going
to happen.

> That way those symbols would only be used if it were explicitly added to
> the link command.

Doesn't work.  Either you have source or you have an executable.  If the
executable uses the old interface and is dynamically linked, there is no
link command, only ldd.  The only control you have is LD_LIBRARY_PATH or
equivalent. (OK, you might also have an old library, and there you could
use a link command).

> For those sites that didn't care about using the 
> previously reserved symbols, it could be automatically linked or even be
> included as a separate object in the standard library.

We can't put the old interfaces in the standard library.  If we get to the
point that g++ is essentially standard-conforming, it would be a disaster
to then completely break standards conformance for the sake of g++-2.7.x
or even g++-2.8.x compatibility.  If a means were provided, it would have
to be done in a way that extra action is required to get the compatibility
stuff -- explicitly point to an old library or a compatibility library.