Solaris patches and results

Benjamin Kosnik bkoz@redhat.com
Thu Aug 24 13:18:00 GMT 2000


> I'm about to get very busy for ten days or so.  Here is the progress I've
> made so far on Solaris, as another data point.

Thanks. I think I will get to this hopefully at the beginning of next week.

> The second file are the testsuite build errors during "make check-install".
> Obviously none of the unicode tests passed with --disable-wchar, but at least
> they mostly compiled.  The __P is not guarded on Solaris, but not
> impossible to work around.  I don't have any thoughts on the iconv stuff yet.

Hmmm. Hmmm..... yeah. This is going to be interesting. Basically, I want 
to get the ctype stuff done too for wchar_t, and then stop, get all 
the platforms building again. I think iconv should work with solaris 2.7 
and later, so it will be interesting to see if this is a correct 
assumption, or if I'm going to be completely hosed....

> The third file -- and this is the real hacky part -- is a trivial patch to
> allow a /usr/include/sys/cdefs.h from a RedHat 6.2 system to be put into
> $srcdir/libio/sys on Solaris.  Note that the file still has to be hand-copied
> into an installation directory, if you go that far in testing.  Eventually
> maybe we won't need this at all.

This can't be right. I need to figure out what is going on here...

> In the --disable-char case, things like mbstate_t/__mbstate_t have
> workarounds or dummies.  (Some were already in place.)  There are some
> functions that don't have much meaning in a narrow-char-only environment, so
> they have truly stub implementations (probably broken).  These things get
> used in other places, so we can't just not compile them.  One in particular
> (_IO_fwide) doesn't really need to be there, but gets referenced, so all the
> shared-library tests fail at loadtime if it isn't.

Hmm. Interesting. Although this seems scary, I think this is the right 
approach.

> Some of the patch was fixing typos and stuff that doesn't affect building,
> but got backed out in the reversion, so they showed up in the diff.  Trim as
> you like.

I'll probably just re-add your files, but with corrections. I'll do this 
later.

> After applying all those patches, and regenerating, and configuring with
> --disable-char, you should be getting testsuite results similar to those
> below.  Unless I horked something again.  :-)

> - 5	0.048	452955	5664		17_intro/header_iostream.cc
> + 4	0.035	2289	44		17_intro/header_iostream.cc
> 
> - 12	0.041	453307	5664		17_intro/headers.cc
> + 11	0.035	3249	60		17_intro/headers.cc
> 
> - 7	0.043	247153	3952		21_strings/append.cc
> + 6	0.039	64612	168		21_strings/append.cc
> 
> - 5	0.033	233601	3952		21_strings/ctor_copy_dtor.cc
> + 5	1181.255	51466	184		21_strings/ctor_copy_dtor.cc
> 
> - 6	0.057	222197	3952		21_strings/element_access.cc
> + 4	0.359	19246	168		21_strings/element_access.cc
> 
> - 6	0.040	236573	3952		21_strings/insert.cc
> + 6	76.832	56527	184		21_strings/insert.cc
> 
> - 5	0.034	226845	3952		21_strings/substr.cc
> + 4	0.040	34189	168		21_strings/substr.cc
> 
> - 7	0.043	454099	5728		22_locale/ctype.cc
> + 5	0.040	4554	144		22_locale/ctype.cc
> 
> - 7	0.041	455731	5664		22_locale/ctype_char_members.cc
> + 5	0.035	7655	80		22_locale/ctype_char_members.cc
> 
> - 8	0.047	459715	5680		23_containers/bitset_ctor.cc
> + 7	0.043	37169	200		23_containers/bitset_ctor.cc
> 
> - 12	1.254	474987	8752		23_containers/bitset_shift.cc
> + 10	1.120	39243	3272		23_containers/bitset_shift.cc
> 
> - 11	0.047	462187	5664		23_containers/multiset.cc
> + 6	0.000	14529	260		23_containers/multiset.cc
> 
> - 10	0.031	491295	5664		23_containers/vector_ctor.cc
> + 9	0.037	42779	96		23_containers/vector_ctor.cc
> 
> - 10	0.032	457639	5664		26_numerics/binary_closure.cc
> + 9	0.000	8621	196		26_numerics/binary_closure.cc
> 
> - 6	0.044	455311	5664		27_io/ios_members.cc
> + 5	0.039	21003	176		27_io/ios_members.cc
> 
> - 13	0.043	453907	5664		27_io/narrow_stream_objects.cc
> + 12	0.000	5552	640		27_io/narrow_stream_objects.cc
> 
> - 25	0.041	453339	5664		27_io/wide_stream_objects.cc
> + 13	0.035	3281	60		27_io/wide_stream_objects.cc

These results are really weird. The shared executables pass, but the 
statically-linked ones are not correct? I'd think they'd both fail.

(I'm seeing this on linux as well--it appears to be related to 
-Wl,--gc-sections, but it's not anything obvious.) 

-benjamin



More information about the Libstdc++ mailing list