Re: solaris patch

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

On Wed, Oct 25, 2000 at 08:56:18AM -0700, Benjamin Kosnik wrote:
> Phil, I'd like you to try current CVS, and see how David's suggestions
> work on solaris (WRT using os_defines vs libio.h ifdefs) . If it's
> pretty straightforward, then I'd appreciate hearing this before you
> try to auto-gen _G_config.h.

It's pretty straightforward.


> Also, perhaps this would be a good time to make sense of the
> libio/Makefile.am based on yesterday's email.........

I've tweaked that like I mentioned (merging the need_xtra stuff).  No build
problems so far (except for that freaky modff thing), but I won't be able
to test the changes on Linux until this afternoon.

The testsuite results are hideous.  Just about every shared executable
cores with a bus error:


52% gdb -nw testsuite/header_ciso646.sh-exe core.header_ciso646.sh-exe.20770 
Core was generated by `/tec/build/3test/sparc-sun-solaris2.8/libstdc++-v3/testsuite/header_ciso646.sh-'.
Program terminated with signal 10, Bus Error.
Reading symbols from /tec/build/Ebuild/lib/libstdc++.so.3...done.
Loaded symbols for /tec/build/Ebuild/lib/libstdc++.so.3
Reading symbols from /opt/SUNWspro/lib/libm.so.1...done.
Loaded symbols for /opt/SUNWspro/lib/libm.so.1
Reading symbols from /usr/lib/libc.so.1...done.
Loaded symbols for /usr/lib/libc.so.1
Reading symbols from /usr/lib/libdl.so.1...done.
Loaded symbols for /usr/lib/libdl.so.1
Reading symbols from /usr/platform/SUNW,Ultra-30/lib/libc_psr.so.1...done.
Loaded symbols for /usr/platform/SUNW,Ultra-30/lib/libc_psr.so.1
#0  0xff2fa2a4 in _IO_file_overflow (f=0x22a17, ch=3)
    at ../../../../unified/libstdc++-v3/libio/fileops.c:489
489       if (f->_flags & _IO_NO_WRITES) /* SET ERROR */
Current language:  auto; currently c
(gdb) bt
#0  0xff2fa2a4 in _IO_file_overflow (f=0x22a17, ch=3)
    at ../../../../unified/libstdc++-v3/libio/fileops.c:489
#1  0xff33f42c in std::basic_filebuf<char, std::char_traits<char> >::close (
    this=0x22a50)
    at ../../../../unified/libstdc++-v3/include/bits/fstream.tcc:174
#2  0xff31e8f4 in std::basic_filebuf<char, std::char_traits<char> >::~basic_filebuf (this=0x22a50, __in_chrg=3)
    at ../../../../unified/libstdc++-v3/include/bits/std_fstream.h:94
#3  0xff306470 in std::ios_base::Init::~Init (this=0xff38ba68, __in_chrg=2)
    at ../../../../unified/libstdc++-v3/src/ios.cc:165
#4  0xff307540 in __static_initialization_and_destruction_0 (__initialize_p=0, 
    __priority=65535)
    at ../../../../unified/libstdc++-v3/include/bits/std_fstream.h:55
#5  0xff307580 in global destructors keyed to std::__ios_flags::_S_boolalpha ()
    at ../../../../unified/libstdc++-v3/include/bits/std_fstream.h:94
#6  0xff2f2058 in __do_global_dtors_aux ()
   from /tec/build/Ebuild/lib/libstdc++.so.3
#7  0xff35e780 in _fini () from /tec/build/Ebuild/lib/libstdc++.so.3
#8  0xff3ca964 in ?? ()
#9  0xff3caad4 in ?? ()
#10 0xff19b4b8 in _exithandle () from /usr/lib/libc.so.1
#11 0xff21a380 in exit () from /usr/lib/libc.so.1

It is however an improvement over last week, where shared executables
couldn't be built at all.

Static executables often fail to link:

/tec/build/Ebuild/bin/g++ -g3 -DDEBUG_ASSERT -ffunction-sections
  -fdata-sections  -static -I../../../unified/libstdc++-v3/testsuite
  -L/tec/build/Ebuild/lib          -Wl,--rpath -Wl,/tec/build/Ebuild/lib
  ../../../unified/libstdc++-v3/testsuite/17_intro/header_iostream.cc -o
  /tec/build/3test/sparc-sun-solaris2.8/libstdc++-v3/testsuite/header_iostream.st-exe
collect2: ld terminated with signal 10 [Bus Error]
/usr/lib/libc.a(iconv.o): In function `iconv_open_private':
iconv.o(.text+0x



-- 
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.