[Bug boehm-gc/37017] New: [4.2 regression] Using --enable-threads=solaris breaks near end of build in boehm-gc configury

[Bug boehm-gc/37017] New: [4.2 regression] Using --enable-threads=solaris breaks near end of build in boehm-gc configury

[rob1weld at aol dot com]

When configuring with --enable-threads=solaris the build runs for hours and
then breaks after the libgfortran finished when configuring boehm-gc . 

It would be nice if the main configure script caught this instead of the build
failing just as it was about to finish.

I am building gcc-4.2.3 release from:
ftp://ftp.gnu.org/gnu/gcc/gcc-4.2.3/gcc-4.2.3.tar.bz2


A similar complaint is made here:

Fortran and objc Hans Boehm GC build issues -- sparcv9 libs
http://gcc.gnu.org/ml/gcc-help/2006-09/msg00108.html


A claim that configuring with --enable-threads=solaris  was fixed is made here:

[4.1/4.2 regression] libstdc++ cannot be build with Solaris threads
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28247


If you are going to build this you need to fixup the Makefiles to get
"--with-gmp=/opt/gnu/gmp-4.2.2 --with-mpfr=/opt/gnu/mpfr-2.3.1" to work, yet
"--with-libiconv-prefix=/opt/csw" works fine.


# gcc/xgcc -v
Using built-in specs.
Target: i386-pc-solaris2.11
Configured with: /aux0/gcc-4.2.3/configure --build=i386-pc-solaris2.11
--prefix=/opt/gnu/gcc --with-docdir=/opt/gnu/gcc/share/doc
--with-htmldir=/opt/gnu/gcc/share/html --with-local-prefix=/opt/gnu
--with-gxx-include-dir=/opt/gnu/gcc/include/c++/4.2.3 --with-as=/opt/gnu/bin/as
--with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld
--with-gmp=/opt/gnu/gmp-4.2.2 --with-mpfr=/opt/gnu/mpfr-2.3.1
--with-libiconv-prefix=/opt/csw --enable-shared --disable-static
--enable-threads=solaris --enable-parallel-mark --enable-libada
--enable-libgcj-debug --enable-libgcj-multifile
--enable-gather-detailed-mem-stats --enable-libssp --disable-libmudflap
--enable-libgomp --enable-libstdcxx-debug --enable-local-sockets
--enable-multilib --enable-nls --enable-objc-gc --enable-portable-native-sync
--enable-tool-wrappers --enable-version-specific-runtime-libs --verbose
--with-dwarf2 --with-stabs --with-tls --enable-decimal-float --with-x
--x-includes=/usr/include/X11 --x-libraries=/usr/X11/lib --enable-gtk-cairo
--enable-qt-peer --enable-gconf-peer --enable-gc-debug
--enable-default-toolkit=xlib --enable-java-awt=gtk,xlib,qt,x
--enable-stage1-checking=release
--enable-languages=c,ada,c++,fortran,java,objc,obj-c++ : (reconfigured)
/aux0/gcc-4.2.3/configure --build=i386-pc-solaris2.11 --prefix=/opt/gnu/gcc
--with-docdir=/opt/gnu/gcc/share/doc --with-htmldir=/opt/gnu/gcc/share/html
--with-local-prefix=/opt/gnu
--with-gxx-include-dir=/opt/gnu/gcc/include/c++/4.2.3 --with-as=/opt/gnu/bin/as
--with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld
--with-gmp=/opt/gnu/gmp-4.2.2 --with-mpfr=/opt/gnu/mpfr-2.3.1
--with-libiconv-prefix=/opt/csw --enable-shared --disable-static
--enable-threads=solaris --enable-parallel-mark --enable-libada
--enable-libgcj-debug --enable-libgcj-multifile
--enable-gather-detailed-mem-stats --enable-libssp --disable-libmudflap
--enable-libgomp --enable-libstdcxx-debug --enable-local-sockets
--enable-multilib --enable-nls --enable-objc-gc --enable-portable-native-sync
--enable-tool-wrappers --enable-version-specific-runtime-libs --verbose
--with-dwarf2 --with-stabs --with-tls --enable-decimal-float --with-x
--x-includes=/usr/include/X11 --x-libraries=/usr/X11/lib --enable-gtk-cairo
--enable-qt-peer --enable-gconf-peer --enable-gc-debug
--enable-default-toolkit=xlib --enable-java-awt=gtk,xlib,qt,x
--enable-stage1-checking=release
--enable-languages=c,ada,c++,fortran,java,objc,obj-c++ : (reconfigured) 
Thread model: solaris
gcc version 4.2.3


Partial build backscroll:

(cd .libs && rm -f libgfortran.so.2 && ln -s libgfortran.so.2.0.0
libgfortran.so.2)
(cd .libs && rm -f libgfortran.so && ln -s libgfortran.so.2.0.0 libgfortran.so)
creating libgfortran.la
(cd .libs && rm -f libgfortran.la && ln -s ../libgfortran.la libgfortran.la)
true  DO=all multi-do # gmake
gmake[6]: Leaving directory
`/aux0/gcc-4.2.3_build/i386-pc-solaris2.11/amd64/libgfortran'
gmake[5]: Leaving directory
`/aux0/gcc-4.2.3_build/i386-pc-solaris2.11/amd64/libgfortran'
gmake[4]: Leaving directory
`/aux0/gcc-4.2.3_build/i386-pc-solaris2.11/libgfortran'
gmake[3]: Leaving directory
`/aux0/gcc-4.2.3_build/i386-pc-solaris2.11/libgfortran'
gmake[2]: Leaving directory
`/aux0/gcc-4.2.3_build/i386-pc-solaris2.11/libgfortran'
Checking multilib configuration for boehm-gc...
mkdir i386-pc-solaris2.11/boehm-gc
Configuring in i386-pc-solaris2.11/boehm-gc
configure: creating cache ./config.cache
checking build system type... i386-pc-solaris2.11
...
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
appending configuration tag "CXX" to libtool
checking for thread model used by GCC... solaris
configure: error: thread package solaris not yet supported
gmake[1]: *** [configure-target-boehm-gc] Error 1
gmake[1]: Leaving directory `/aux0/gcc-4.2.3_build'
gmake: *** [all] Error 2


-- 
           Summary: [4.2 regression] Using --enable-threads=solaris breaks
                    near end of build in boehm-gc configury
           Product: gcc
           Version: 4.2.3
            Status: UNCONFIRMED
          Severity: blocker
          Priority: P3
         Component: boehm-gc
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: rob1weld at aol dot com
 GCC build triplet: i386-pc-solaris2.11
  GCC host triplet: i386-pc-solaris2.11
GCC target triplet: i386-pc-solaris2.11


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37017

[Bug boehm-gc/37017] Using --enable-threads=solaris breaks near end of build in boehm-gc configury

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2008-08-03 23:08 -------
I really don't think using solaris threads is that well supported anymore.  Is
there a reason why you are not using just --enable-threads=pthreads?


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|blocker                     |normal
            Summary|[4.2 regression] Using --   |Using --enable-
                   |enable-threads=solaris      |threads=solaris breaks near
                   |breaks near end of build in |end of build in boehm-gc
                   |boehm-gc configury          |configury


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37017

[Bug boehm-gc/37017] Using --enable-threads=solaris breaks near end of build in boehm-gc configury

[rob1weld at aol dot com]

------- Comment #2 from rob1weld at aol dot com  2008-08-04 01:28 -------
> Is there a reason why you are not using just --enable-threads=pthreads?

A few reasons. 

1. I test _all_ of gcc's configure options, submit bug reports and email test
results - "--enable-threads=solaris" is a valid choice.

2. There are more features on this Operating System. With Solaris it enables
Solaris threads _and_ pthreads simultaneously.

man threads(5)
http://opensolaris.org/os/community/arc/caselog/2008/039/materials/new_man/threads-5/

Comparing APIs for Solaris Threads and POSIX Threads
http://docs.sun.com/app/docs/doc/816-5137/sthreads-96692?l=en&a=view

Unique Solaris Threads Functions
http://docs.sun.com/app/docs/doc/816-5137/sthreads-49113?l=en&a=view

-----

Here is a quick fix to allow the build to continue. I still need to run "make
-i check" on this:


# gdiff -Naur /aux0/gcc-4.2.3/boehm-gc/configure_Origonal
/aux0/gcc-4.2.3/boehm-gc/configure  
--- /aux0/gcc-4.2.3/boehm-gc/configure_Origonal 2007-10-07 14:23:16.000000000
-0700
+++ /aux0/gcc-4.2.3/boehm-gc/configure  2008-08-03 18:00:52.633231123 -0700
@@ -5500,6 +5500,13 @@
        multi_os_directory=`$CC -print-multi-os-directory`
        THREADLIBS="-L/usr/lib/lwp/$multi_os_directory \
                    -R/usr/lib/lwp/$multi_os_directory -lpthread -lthread -lrt"
+
+        if test "${enable_parallel_mark}" = yes; then
+cat >>confdefs.h <<\_ACEOF
+#define PARALLEL_MARK 1
+_ACEOF
+       fi
+                           
        ;;
      *-*-irix*)

@@ -5602,16 +5609,17 @@
 _ACEOF

     ;;
- decosf1 | irix | mach | os2 | solaris | dce | vxworks)
+# decosf1 | irix | mach | os2 | solaris | dce | vxworks)
+ decosf1 | irix | mach | os2 | dce | vxworks)
     { { echo "$as_me:$LINENO: error: thread package $THREADS not yet
supported" >&5
 echo "$as_me: error: thread package $THREADS not yet supported" >&2;}
    { (exit 1); exit 1; }; }
     ;;
- *)
-    { { echo "$as_me:$LINENO: error: $THREADS is an unknown thread package"
>&5
-echo "$as_me: error: $THREADS is an unknown thread package" >&2;}
-   { (exit 1); exit 1; }; }
-    ;;
+# *)
+#    { { echo "$as_me:$LINENO: error: $THREADS is an unknown thread package"
>&5
+#echo "$as_me: error: $THREADS is an unknown thread package" >&2;}
+#   { (exit 1); exit 1; }; }
+#    ;;
 esac

-----

Note: I unnecessarily added the "parallel mark" feature also.


-- 

rob1weld at aol dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |blocker


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37017

[Bug boehm-gc/37017] Using --enable-threads=solaris breaks near end of build in boehm-gc configury

[rob1weld at aol dot com]

------- Comment #3 from rob1weld at aol dot com  2008-08-04 18:44 -------
> I wrote:
> It would be nice if the main configure script caught this instead of the build
failing just as it was about to finish.

But then I would not have to try fixing this ...

The boehm-gc directory built correctly and the build continues until we get to
the libjava directory that fails with this error:

...
checking for remove... yes
checking for shmat... yes
checking for IceConnectionNumber in -lICE... yes
checking for garbage collector to use... boehm
checking for thread model used by GCC... solaris
configure: error: thread package solaris not yet supported
gmake[2]: *** [config.status] Error 1
gmake[2]: Leaving directory `/aux0/gcc-4.2.3_build/i386-pc-solaris2.11/libjava'
gmake[1]: *** [all-target-libjava] Error 2
gmake[1]: Leaving directory `/aux0/gcc-4.2.3_build'
gmake: *** [all] Error 2


The _matching_ portions of the "gcc-4.2.3/boehm-gc/configure" and the
"gcc-4.2.3/libjava/configure" can be fixed the same way.


The libjava configure has a few problems:

1. Libjava can be configured to use the Boehm Garbage Collection - so the
configuring should matchup the threading types and options more closely.

2. Another huge bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37019

3. Various parts in "libjava/configure" make assumtions that are not true
and are not the same as those made in "boehm-gc/configure":

EG: 

In the "case "$THREADS" in" section (line 5354 in "boehm-gc/configure" and line
9109 in libjava/configure) the boehm configury separates the various Operating
Systems in a more fine-grained manner than is done in the libjava configury.


The libjava configury checks for these thread types (with only ONE case
statement used for "*-*-linux*" and (much later) a few more OS types are
checked):

no | none | single)
posix | posix95 | pthreads)
    case "$host" in
     *-*-linux*)
cat >>confdefs.h <<\_ACEOF
#define LINUX_THREADS 1
_ACEOF
        ;;
    esac
win32)
decosf1 | irix | mach | os2 | solaris | dce | vxworks)
...
case "$THREADS" in
 posix)
    case "$host" in
     *-*-cygwin*)
        # Don't set THREADLIBS here.  Cygwin doesn't have -lpthread.
        ;;
     *-*-freebsd[1234]*)
        # Before FreeBSD 5, it didn't have -lpthread (or any library which
        # merely adds pthread_* functions) but it does have a -pthread switch
        # which is required at link-time to select -lc_r *instead* of -lc.
        THREADLDFLAGS=-pthread
        # Don't set THREADSPEC here as might be expected since -pthread is
        # not processed when found within a spec file, it must come from
        # the command line.  For now, the user must provide the -pthread
        # switch to link code compiled with gcj.  In future, consider adding
        # support for weak references to pthread_* functions ala gthr.h API.
        THREADSPEC='%{!pthread: %{!shared: %eUnder this configuration, the user
must provide -pthread when linking.}}'
        ;;
     *-*-freebsd*)
        # FreeBSD >=5.3 implements a model much closer to other modern UNIX
        # systems which support threads and -lpthread.
        THREADLDFLAGS=-pthread
        THREADSPEC=-lpthread
        ;;
     alpha*-dec-osf* | hppa*-hp-hpux*)
        THREADCXXFLAGS=-pthread
        # boehm-gc needs some functions from librt, so link that too.
        THREADLIBS='-lpthread -lrt'
        THREADSPEC='-lpthread -lrt'
        ;;
     *)
        THREADLIBS=-lpthread
        THREADSPEC=-lpthread
        ;;
    esac
    THREADH=posix-threads.h
    # MIT pthreads doesn't seem to have the mutexattr functions.
    # But for now we don't check for it.  We just assume you aren't
    # using MIT pthreads.
cat >>confdefs.h <<\_ACEOF
#define HAVE_PTHREAD_MUTEXATTR_INIT 1
_ACEOF
    # If we're using the Boehm GC, then we happen to know that it
    # defines _REENTRANT, so we don't bother.  Eww.
    if test "$GC" != boehm; then
cat >>confdefs.h <<\_ACEOF
#define _REENTRANT 1
_ACEOF
    fi
cat >>confdefs.h <<\_ACEOF
#define _POSIX_PTHREAD_SEMANTICS 1
_ACEOF
    ;;
 win32)
    THREADH=win32-threads.h
    THREADCXXFLAGS=-mthreads
    # We need thread-safe exception handling so _CRT_MT should be set to 1.
    # But we do not want the executables created to be dependent on
    # mingwm10.dll which provides a __mingwthr_key_dtor() that cleans up
    # exception handling contexts.  The following kludge achieves this effect
    # and causes a dummy __mingwthr_key_dtor() to be linked in from
    # libmingw32.a.  This causes a memory leak of about 24 bytes per thread.
    # A workaround is to explicitly use -mthreads while linking Java programs.
    # See PR libgcj/28263.
    #
    # FIXME: In Java we are able to detect thread death at the end of
    # Thread.run() so we should be able to clean up the exception handling
    # contexts ourselves.
    THREADSTARTFILESPEC='crtmt%O%s'
    ;;
 none)
    THREADH=no-threads.h
    ;;
esac
          ac_config_links="$ac_config_links
include/java-threads.h:include/$THREADH"



The boehm-gc configury checks for these thread types AND has additional cases
for various OS types to set additional features:

no | none | single)
posix | posix95 | pthreads)
    case "$host" in
     x86-*-linux* | ia64-*-linux* | i586-*-linux* | i686-*-linux* |
x86_64-*-linux* | alpha-*-linux*)
cat >>confdefs.h <<\_ACEOF
#define GC_LINUX_THREADS 1
_ACEOF
cat >>confdefs.h <<\_ACEOF
#define _REENTRANT 1
_ACEOF
        if test "${enable_parallel_mark}" = yes; then
cat >>confdefs.h <<\_ACEOF
#define PARALLEL_MARK 1
_ACEOF
        fi
cat >>confdefs.h <<\_ACEOF
#define THREAD_LOCAL_ALLOC 1
_ACEOF
        ;;
     *-*-linux*)
        cat >>confdefs.h <<\_ACEOF
#define GC_LINUX_THREADS 1
_ACEOF
        cat >>confdefs.h <<\_ACEOF
#define _REENTRANT 1
_ACEOF
        ;;
     *-*-aix*)
cat >>confdefs.h <<\_ACEOF
#define GC_AIX_THREADS 1
_ACEOF
        cat >>confdefs.h <<\_ACEOF
#define _REENTRANT 1
_ACEOF
        ;;
     *-*-hpux11*)
        { echo "$as_me:$LINENO: WARNING: \"Only HP-UX 11 POSIX threads are
supported.\"" >&5
echo "$as_me: WARNING: \"Only HP-UX 11 POSIX threads are supported.\"" >&2;}
cat >>confdefs.h <<\_ACEOF
#define GC_HPUX_THREADS 1
_ACEOF
cat >>confdefs.h <<\_ACEOF
#define _POSIX_C_SOURCE 199506L
_ACEOF
        if test "${enable_parallel_mark}" = yes; then
          cat >>confdefs.h <<\_ACEOF
#define PARALLEL_MARK 1
_ACEOF
        fi
        cat >>confdefs.h <<\_ACEOF
#define THREAD_LOCAL_ALLOC 1
_ACEOF
        THREADLIBS="-lpthread -lrt"
        # HPUX needs REENTRANT for the _r calls.
cat >>confdefs.h <<\_ACEOF
#define _REENTRANT 1
_ACEOF
        ;;
     *-*-hpux10*)
        { echo "$as_me:$LINENO: WARNING: \"Only HP-UX 11 POSIX threads are
supported.\"" >&5
echo "$as_me: WARNING: \"Only HP-UX 11 POSIX threads are supported.\"" >&2;}
        ;;
      *-*-kfreebsd*-gnu)
       cat >>confdefs.h <<\_ACEOF
#define GC_FREEBSD_THREADS 1
_ACEOF
       INCLUDES="$INCLUDES -pthread"
       THREADDLLIBS=-pthread
       cat >>confdefs.h <<\_ACEOF
#define _REENTRANT 1
_ACEOF
         if test "${enable_parallel_mark}" = yes; then
         cat >>confdefs.h <<\_ACEOF
#define PARALLEL_MARK 1
_ACEOF
       fi
       cat >>confdefs.h <<\_ACEOF
#define THREAD_LOCAL_ALLOC 1
_ACEOF
cat >>confdefs.h <<\_ACEOF
#define USE_COMPILER_TLS 1
_ACEOF
               ;;
     *-*-freebsd*)
        { echo "$as_me:$LINENO: WARNING: \"FreeBSD does not yet fully support
threads with Boehm GC.\"" >&5
echo "$as_me: WARNING: \"FreeBSD does not yet fully support threads with Boehm
GC.\"" >&2;}
cat >>confdefs.h <<\_ACEOF
#define GC_FREEBSD_THREADS 1
_ACEOF
        AM_CPPFLAGS="$AM_CPPFLAGS -pthread"
        THREADLIBS=-pthread
        ;;
     *-*-solaris*)
cat >>confdefs.h <<\_ACEOF
#define GC_SOLARIS_PTHREADS 1
_ACEOF
        # Need to use alternate thread library, otherwise gctest hangs
        # on Solaris 8.
        multi_os_directory=`$CC -print-multi-os-directory`
        THREADLIBS="-L/usr/lib/lwp/$multi_os_directory \
                    -R/usr/lib/lwp/$multi_os_directory -lpthread -lthread -lrt"
        if test "${enable_parallel_mark}" = yes; then
cat >>confdefs.h <<\_ACEOF
#define PARALLEL_MARK 1
_ACEOF
        fi
        ;;
     *-*-irix*)
cat >>confdefs.h <<\_ACEOF
#define GC_IRIX_THREADS 1
_ACEOF
        ;;
     *-*-cygwin*)
cat >>confdefs.h <<\_ACEOF
#define GC_WIN32_THREADS 1
_ACEOF
        ;;
     *-*-darwin*)
cat >>confdefs.h <<\_ACEOF
#define GC_DARWIN_THREADS 1
_ACEOF
        cat >>confdefs.h <<\_ACEOF
#define THREAD_LOCAL_ALLOC 1
_ACEOF
        if test "${enable_parallel_mark}" = yes; then
          cat >>confdefs.h <<\_ACEOF
#define PARALLEL_MARK 1
_ACEOF
        fi
        ;;
     *-*-osf*)
cat >>confdefs.h <<\_ACEOF
#define GC_OSF1_THREADS 1
_ACEOF
        if test "${enable_parallel_mark}" = yes; then
          cat >>confdefs.h <<\_ACEOF
#define PARALLEL_MARK 1
_ACEOF
          cat >>confdefs.h <<\_ACEOF
#define THREAD_LOCAL_ALLOC 1
_ACEOF
          # May want to enable it in other cases, too.
          # Measurements havent yet been done.
        fi
        AM_CPPFLAGS="$AM_CPPFLAGS -pthread"
        THREADLIBS="-lpthread -lrt"
        ;;
    esac
    ;;
 win32)
    cat >>confdefs.h <<\_ACEOF
#define GC_WIN32_THREADS 1
_ACEOF
            ;;
 dgux386)
    THREADS=dgux386
echo "$as_me:$LINENO: result: $THREADLIBS" >&5
echo "${ECHO_T}$THREADLIBS" >&6
    # Use pthread GCC  switch
    THREADLIBS=-pthread
    if test "${enable_parallel_mark}" = yes; then
        cat >>confdefs.h <<\_ACEOF
#define PARALLEL_MARK 1
_ACEOF
    fi
    cat >>confdefs.h <<\_ACEOF
#define THREAD_LOCAL_ALLOC 1
_ACEOF
cat >>confdefs.h <<\_ACEOF
#define GC_DGUX386_THREADS 1
_ACEOF
cat >>confdefs.h <<\_ACEOF
#define DGUX_THREADS 1
_ACEOF
    # Enable _POSIX4A_DRAFT10_SOURCE with flag -pthread
    AM_CPPFLAGS="-pthread $AM_CPPFLAGS"
    ;;
 aix)
    THREADS=posix
    THREADLIBS=-lpthread
    cat >>confdefs.h <<\_ACEOF
#define GC_AIX_THREADS 1
_ACEOF
    cat >>confdefs.h <<\_ACEOF
#define _REENTRANT 1
_ACEOF
    ;;
 decosf1 | irix | mach | os2 | dce | vxworks)
...


I see that what threading types are checked for, which OSes they are used on,
and what features are implemented is not consistent between boehm-gc and
libjava even though libjava can use the boehm-gc library.

---

Further on in the libjava/configure file it says this:

      LIBS="$LIBS $THREADLIBS"
      # Some POSIX thread systems don't have pthread_mutexattr_settype.
      # E.g., Solaris.

But this page:
http://docs.sun.com/app/docs/doc/816-5137/sthreads-96692?l=en&a=view says that
it is called "pthread_mutex_attr_settype()" (and
"pthread_mutex_attr_gettype()").

---

Further on in the libjava/configure file it says this:

      # Look for sched_yield.  Up to Solaris 2.6, it is in libposix4, since
      # Solaris 7 the name librt is preferred.

so it seems to be trying to use threading in Solaris but only if posix threads
are chosen (but choosing "solaris" threads would give us "sched_yield" (and the
Solaris version "thr_yield" also)).



> Andrew Pinski  2008-08-03 23:08 wrote:
> I really don't think using solaris threads is that well supported anymore.

The "support" is there, it is just broken in a few spots and needs a once-over
by someone more familiar with Solaris than me (but I'll give it a go). 

There are inconsistencies between the various library's thread options that
would need to be addressed (even _IF_ you plan to remove the
"--enable-threads=solaris" option) to ensure that the Posix options are
consistent.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37017

[Bug boehm-gc/37017] Using --enable-threads=solaris breaks near end of build in boehm-gc configury

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|blocker                     |normal


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37017

[Bug boehm-gc/37017] Using --enable-threads=solaris breaks near end of build in boehm-gc configury

[rob1weld at aol dot com]

------- Comment #4 from rob1weld at aol dot com  2009-01-20 04:05 -------
(In reply to comment #1)
> I really don't think using solaris threads is that well supported anymore.  Is
> there a reason why you are not using just --enable-threads=pthreads?

I have another reason for the compiler to support Solaris threading
on this Platform, it is 'expected' by gdb. This is from code compiled by:
gcc version 4.4.0 20090117 (experimental) [trunk revision 143454].

# gdb simtest
GNU gdb (GDB) 6.8.50.20090115-cvs
(gdb) b 8
Breakpoint 1 at 0x804883f: file simtest.f, line 8.
(gdb) r
Starting program: /usr/share/src/gcc_build/gcc/testsuite/gcc/simtest 
warning: rw_common (): unable to read at addr 0x155708
warning: sol_thread_new_objfile: td_ta_new: Debugger service failed
warning: Unable to find dynamic linker breakpoint function.
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code.

Breakpoint 1, MAIN__ () at simtest.f:8
8             call sub
(gdb) 


The "warning: sol_thread_new_objfile" line is from: 'gdb-6.8/gdb/sol-thread.c'.

static void
sol_thread_new_objfile (struct objfile *objfile)
{
  td_err_e val;
...
  if (val == TD_NOLIBTHREAD)
    return;
  else if (val != TD_OK)
    {
      warning (_("sol_thread_new_objfile: td_ta_new: %s"), td_err_string
(val));
      return;
    }

  sol_thread_active = 1;
}


Between ./configuring using "--with-gnu-as --with-as=/usr/local/bin/as 
--with-gnu-ld --with-ld=/usr/local/bin/ld" and using the Posix thread 
model on i386-pc-solaris2.11 we end up confusing gdb build with an unusual
Solaris configuration.

Gdb expects the Solaris Platform to be different than what gcc is providing
and for Solaris' compiler (_even_ _if_ it is gcc) to support the model
--enable-threads=solaris . 

This is due to gdb's expectation that the libthread_db and libthread
provided by the Operating System are in use. If we can not build the
compiler with the correct options for this Platform then gdb suffers.

When we get that warning it also means "sol_thread_active != 1" .

While it would be correct for gdb to fix _their_ configury to correctly
_detect_ the features that are available we should also fix _our_ 
configury to correctly _provide_ the features we need.

Rob


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37017

[Bug boehm-gc/37017] Using --enable-threads=solaris breaks near end of build in boehm-gc configury

[ro at gcc dot gnu dot org]

------- Comment #5 from ro at gcc dot gnu dot org  2010-04-28 20:40 -------
Unless there are very important reasons (and I don't see any since the
underlying
libthread and libpthread implementation on Solaris 2 is identical, just the
interfaces differ), please stick with the default, posix.  This is now
documented
in install.texi to deter people who think they should use solaris on Solaris 2.


-- 

ro at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ro at gcc dot gnu dot org
             Status|UNCONFIRMED                 |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37017

[Bug boehm-gc/37017] Using --enable-threads=solaris breaks near end of build in boehm-gc configury

[rob1weld at aol dot com]

------- Comment #6 from rob1weld at aol dot com  2010-05-04 07:00 -------
>> Unless there are very important reasons (and I don't see any since the
>> underlying libthread and libpthread implementation on Solaris 2 is identical, >> just the interfaces differ), please stick with the default, posix.  

_My_ reasons to test it for the "gcc group" was that "--enable-threads=solaris"
_was_ a legal configuration option and so I tested it and made a BR. My reasons
were set out in comments 2 and 4, I have nothing to add.


>> This is now documented in install.texi to deter people who think they should >> use solaris on Solaris 2.
Thanks for fixing the DOCs, can we pull the code too (or ifdef it out for
OpenSolaris) to avoid having code in gcc that is no longer supported.

Rob


-- 

rob1weld at aol dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |UNCONFIRMED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37017

[Bug boehm-gc/37017] Using --enable-threads=solaris breaks near end of build in boehm-gc configury

[ro at CeBiTec dot Uni-Bielefeld dot DE]

------- Comment #7 from ro at CeBiTec dot Uni-Bielefeld dot DE  2010-05-06 19:17 -------
Subject: Re:  Using --enable-threads=solaris breaks near end of build in
boehm-gc configury

> ------- Comment #6 from rob1weld at aol dot com  2010-05-04 07:00 -------

>>> This is now documented in install.texi to deter people who think they should >> use solaris on Solaris 2.
> Thanks for fixing the DOCs, can we pull the code too (or ifdef it out for
> OpenSolaris) to avoid having code in gcc that is no longer supported.

This has nothing to do with OpenSolaris, just the fact that some target
libraries don't work with --enable-threads=solaris, while others work
just fine.  No real reason to pull it out, though I could be persaded to
do so given that there's no benefit in keeping it.

        Rainer


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37017

[Bug boehm-gc/37017] Using --enable-threads=solaris breaks near end of build in boehm-gc configury

[ro at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37017

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |WONTFIX
         AssignedTo|unassigned at gcc dot       |ro at gcc dot gnu.org
                   |gnu.org                     |
   Target Milestone|---                         |4.7.0

--- Comment #8 from Rainer Orth <ro at gcc dot gnu.org> 2011-03-28 19:48:07 UTC ---
Support for --with-threads=solaris has been removed for GCC 4.7.0.  It isn't
resonably supported in the target libraries and untested, so no point in
spending
time on this issue.