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