Re: libstdc++v3 portability problems

[Phil Edwards <pedwards at disaster dot jaj dot com>]

[As a side note, please cc any future libstdc++-v3 issues to the libstdc++-v3
list.  It's easy for things to get swamped in the gcc list.]


On Fri, Dec 08, 2000 at 11:27:05AM -0600, Robert Lipe wrote:
> 
> 1) Calls to 'ar rc' with no files to add.   GNU ar supports this.
>    Phil delivered a patch, but others were unhappy with it so it never
>    reached closure

Phil needed to review the Automake manual again.  :-)  An updated patch
is below.  (It's the same thing, almost, but incorporates Alexandre's "keep
it simple" suggestion.)  Tested on sparc-sun-solaris2.8.  I'll probably
check this one in unless someone complains today.

Don't forget to regenerate after patching; I use

    % type autoall
    autoall is aliased to `aclocal && autoconf && autoheader && automake'
    %

as a brute-force solution.


> 2) 'make check' in the libstdc++v3 build diredtory calls scripts that
>    have implicit dependencies on bash.   Nested shell functions are
>    a bash extension and not available on POSIX shells.

That's in the works already... sigh, mkcheck wasn't supposed to survive
in its current form quite this long.

Anyhow, Gaby is converting the whole mess to work with dejagnu.
The mkcheck script will then be done with some other target, like "make
timing-and-filesize-check" or "make numbers".

In the meantime, perhaps we should just rename that target now, so that
'make check' is a zero-return no-op?


> 3) Toplevel 'make check' now doesn't work on multilibbed targets.

Hmmm.  I don't about this one, sorry.  (I thought recent Solaris was supposed
to also be multilibbed, but the sparcv9 stuff doesn't seem to be active now.)


> 4) (And I don't know that this is a libstdc++-v3 thing, but while I'm ranting
>     I'll keep the podium for one more minute.) The builds are 
>     getting _really_ obscure throgh the use of libtool/automake magic.

Yup.  It's a very complicated library.  The ISO committee made some things
a little strange.  The library got stranger with "C" shadowing headers,
and more stranger (!) with libsupc++, and more strangerererer still with
every additional platform we need to support.  It's going to get downright
funky before the Java integration is complete.

I can't wait until the next releases of automake and libtool; v3 should
get simpler then.  Until that happens, some things will only get simpler
if we cut out corresponding functionality.

On the plus side -- and this is a big plus -- if we do our job correctly,
a whole bunch of stuff will just /work/ for the end user.  Speaking as an
end user, I'm all for that.  :-)


Phil

-- 
pedwards at disaster dot jaj dot com  |  pme at sources dot redhat dot com
devphil at several other less interesting addresses in various dot domains
The gods do not protect fools.  Fools are protected by more capable fools.


Index: acinclude.m4
===================================================================
RCS file: /cvs/gcc/egcs/libstdc++-v3/acinclude.m4,v
retrieving revision 1.107
diff -u -3 -p -r1.107 acinclude.m4
--- acinclude.m4	2000/12/08 05:57:47	1.107
+++ acinclude.m4	2000/12/08 19:25:05
@@ -1344,6 +1344,8 @@ AC_DEFUN(GLIBCPP_ENABLE_CSTDIO, [
   AC_LINK_FILES($CCODECVT_C, libio/c_codecvt.c)
   # 2000-08-04 bkoz hack
 
+  AM_CONDITIONAL(GLIBCPP_BUILD_LIBIO,
+                 test "$need_libio" = yes || test "$need_wlibio" = yes)
   AM_CONDITIONAL(GLIBCPP_NEED_LIBIO, test "$need_libio" = yes)
   AM_CONDITIONAL(GLIBCPP_NEED_WLIBIO, test "$need_wlibio" = yes)
   if test "$need_libio" = yes || test "$need_wlibio" = yes; then
Index: libio/Makefile.am
===================================================================
RCS file: /cvs/gcc/egcs/libstdc++-v3/libio/Makefile.am,v
retrieving revision 1.17
diff -u -3 -p -r1.17 Makefile.am
--- Makefile.am	2000/10/29 22:32:29	1.17
+++ Makefile.am	2000/12/08 19:25:05
@@ -23,7 +23,11 @@
 
 AUTOMAKE_OPTIONS = 1.3 cygnus
 
+if GLIBCPP_BUILD_LIBIO
 noinst_LTLIBRARIES = libio.la
+else
+noinst_LTLIBRARIES = 
+endif
 
 # Use common includes from acinclude.m4/GLIBCPP_EXPORT_INCLUDES
 GLIBCPP_INCLUDE_DIR = @GLIBCPP_INCLUDE_DIR@