libstdc++v3 portability problems

Robert Lipe robertl@sco.com
Fri Dec 8 09:24:00 GMT 2000


I've just about exceeded the fun quota on this so I'm asking for help.
I've been repeatedly spanked by portability problems in the new library.
Several folks (Phil, Gaby, and Alexandre in particular) have been quite
helpful in closing several items. Still, we seem to have a proliferation
of external dependencies that's unnerving.

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

   http://gcc.gnu.org/ml/gcc/2000-12/msg00132.html

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.

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


Test Run By robertl on Wed Dec  6 05:51:26 2000
Native configuration is i686-pc-sco3.2v5.0.6

		=== g++ tests ===

Schedule of variations:
    unix/-mcoff
    unix/-fPIC
    unix/-melf

Running target unix/-mcoff
Using /usr/local/share/dejagnu/baseboards/unix.exp as board description file for target.
Using /usr/local/share/dejagnu/config/unix.exp as generic interface file for target.
Using /play/egcs/gcc/testsuite/config/default.exp as tool-and-target-specific interface file.
Running /play/egcs/gcc/testsuite/g++.dg/dg.exp ...
couldn't execute "/play/negcs/i686-pc-sco3.2v5.0.6/coff/libstdc++-v3/tests_flags": no such file or directory
    while executing
"exec ${odir_v3}/tests_flags --compiler ${odir_v3} ${sdir_v3}"
    (procedure "g++_include_flags" line 21)
    invoked from within
"g++_include_flags"
    (procedure "g++_init" line 58)
    invoked from within
"${tool}_init $test_file_name"
    (procedure "runtest" line 19)
    invoked from within
"runtest $test_name"
    ("foreach" body line 40)
    invoked from within
"foreach test_name [lsort [find ${dir} *.exp]] {
			if { ${test_name} == "" } {
			    continue
			}
			# Ignore this one if asked to.
			if { ${ignore..."
    ("foreach" body line 3)
    invoked from within
"foreach dir "${test_top_dirs}" {
		if { ${dir} != ${srcdir} } {
		    foreach test_name [lsort [find ${dir} *.exp]] {
			if { ${test_name} == "" } {
	..."
    ("foreach" body line 77)
    invoked from within
"foreach pass $multipass {
	# multipass_name is set for `record_test' to use (see framework.exp).
	if { [lindex $pass 0] != "" } {
	    set multipass_n..."
    ("foreach" body line 26)
    invoked from within
"foreach current_target $target_list {
    verbose "target is $current_target";
    set current_target_name $current_target;
    set tlist [split $curr..."
    (file "/usr/local/share/dejagnu/runtest.exp" line 1576)

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.
    Originally, libstdc++-v3 wouldn't build for me becuase libobjc/configure
    was generated with an old set of the tools.   So I regenerated it.
    Then the top level builds stopped working for other people.   This is
    just an example and I know that this is pretty subjective, but we don't
    seem to have good auditability here.
    
 
Can anyone offer a hand?

Thanx,
RJL


More information about the Gcc mailing list