pkg/44735: pkgsrc 2010Q4 Solaris 2.{8,10} lang/gcc3 build failed (libtool problem ?)

[Wolfgang.Stukenbrock%nagler-company.com@localhost]

>Number:         44735
>Category:       pkg
>Synopsis:       pkgsrc 2010Q4 Solaris 2.{8,10} lang/gcc3 build failed (libtool 
>problem ?)
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    pkg-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Mar 17 13:40:00 +0000 2011
>Originator:     Dr. Wolfgang Stukenbrock
>Release:        NetBSD 4.0
>Organization:
Dr. Nagler & Company GmbH
>Environment:
        
        
System: NetBSD test-s0 4.0 NetBSD 4.0 (NSW-WS) #0: Tue Aug 17 17:28:09 CEST 
2010 wgstuken@test-s0:/usr/src/sys/arch/amd64/compile/NSW-WS amd64
Architecture: x86_64
Machine: amd64
>Description:
        I'm trying to use pkgsrc-2010Q4 on Solaris 2.8 and/or 2.10.
        I want to build only 64-Bit binaries on the system.
        I perfer the sunstudio compilers as default for Solaris, so
        I bootstrap with sunstudio11 (on 2.8) and sunstudio12.1 (on 2.10).
        remark: the 12.1 does not work on our 2.8 system due to libc problems.

        boottrapping works fine with the method described 
        "env CC=/opt/.. SUNWSPROBASE=/opt/... ./bootstrap -abi=64

        The resulting /usr/pkg/etc/mk.conf accedently than needs some tuning,
        because some packages (e.g. automake) will not be prepared for 64 bit
        so "MACHINE_GNU_PLATFORM=   sparc64-sun-solaris2" must be added to it.

        Next gcc3-c will compile with the sunpro compiler fine, but gcc3-c++
        requires a setup with gcc as pkgsrc-compiler.
        There are also some other packages that does not compile with the
        sunpro compiler due to syntax/semantic problems in C or C++.
        (up to now I know fonts/fontconfig and print/poppler, but I'm shure 
there
        are more ...)
        Therefore I've added a 'switch' to support this.
        Here my mk.conf for Solaris 2.10 follows:
# Example /usr/pkg/etc/mk.conf file produced by bootstrap-pkgsrc
# Wed Mar 16 14:27:24 CET 2011

.ifdef BSD_PKG_MK       # begin pkgsrc settings

ABI=                    64
.ifdef NC_PKG_GCC
PKGSRC_COMPILER=        gcc
CC=                     /usr/pkg/gcc3/bin/gcc
CXX=                    /usr/pkg/gcc3/bin/g++
CPP=                    /usr/pkg/gcc3/bin/cpp
.else
PKGSRC_COMPILER=        sunpro
CC=                     cc
CXX=                    CC
CPP=                    ${CC} -E
SUNWSPROBASE=           /opt/sunstudio12.1
.endif
# some ABI 64 settings - required by some tools like automake and gmp ..
MACHINE_GNU_PLATFORM=   sparc64-sun-solaris2

PKG_DBDIR=              /var/db/pkg
LOCALBASE=              /usr/pkg
VARBASE=                /var
PKG_TOOLS_BIN=          /usr/pkg/sbin
PKGMANDIR=              man

TOOLS_PLATFORM.install?=        /usr/pkg/bin/install-sh
TOOLS_PLATFORM.sh?=             /usr/pkg/bin/pdksh
TOOLS_PLATFORM.ksh?=            /usr/pkg/bin/pdksh
TOOLS_PLATFORM.awk?=            /usr/pkg/bin/nawk
TOOLS_PLATFORM.sed?=            /usr/pkg/bin/nbsed
# added by us
TOOLS_PLATFORM.tar?=            /usr/pkg/bin/bsdtar

.endif                  # end pkgsrc settings

        The TOOLS_PLATFORM.tar has been added to avoid possible portabiliy
        problems with the original sun tar that is not 100% compartible with
        gnutar and bsdtar.

        Next problem with gcc3 is that gcc-c++ will run into an endless loop
        with configure. OK normaly this gets "fixed" by setting 
GNU_CONFIGURE=yes
        in the Makefile. This is not done for some reasons.
        If I add the following to lang/gcc3/Makefile.common the endless loop
        disapears and everything compiles corretly.

GNU_CONFIGURE=               yes
USE_GNU_CONFIGURE_HOST=      no
CONFIGURE_HAS_INFODIR=       no
CONFIGURE_HAS_MANDIR=        no
GNU_CONFIGURE_PREFIX= ${GCC_PREFIX}

.if empty(PKGNAME:M*-c-*)
NC_PKG_GCC=1
.endif

        The optional setting of NC_PKG_GCC switches to gcc mode
        for all parts of gcc3 other than gcc3-c.
        Due to the fact, that the --host parameter is added on the configure
        command line in another way, you need to disable the automatic
        parameter setup by disabling USE_GNU_CONFIGURE_HOST.
        I've disabled the additional two CONFIGURE_HAS_INFODIR and 
CONFIGURE_HAS_MANDIR.
        You need to set GNU_CONFIGURE_PREFIX to the correct path /usr/pkg/gcc3,
        because this is added on the command line too. It is there twice now, 
but
        that does not hurt configure ...

        This setup compiles now, but gcc3-c++ still fails to install.
        The problem is the "libtool" - I hate this "stupid" tool ...

        In 
lang/gcc3-c++/work/gcc-3.3.6/sparc64-sun-solaris2/sparcv7/libstdc++-v3
        there is a libtool script that is called during installation and that is
        the cause of the problem.
        For installation it gets called many times with arguments like the 
following:
        /usr/pkg/bin/pdksh 
/export/opt/NC-src/pkgsrc-2010Q4/lang/gcc3-c++/work/gcc-3.3.6/install-sh -c -m 
644 ${file} /usr/pkg/gcc3/include/c++/3.3.6/./ext
        This works fine, because the last path points to a directory.
        But it also gets called the following way:
        /usr/pkg/bin/pdksh ../libtool  --mode=install /usr/pkg/bin/pdksh 
/export/opt/NC-src/pkgsrc-2010Q4/lang/gcc3-c++/work/gcc-3.3.6/install-sh -c 
libsupc++.la /usr/pkg/gcc3/lib/./libsupc++.la
        remark: this is the case in the libsupc++ subdir of the directory 
mentioned
        above.
        Here we have a "file" to "file" install.
        The problem is that the libtool script does not detect 
"/usr/pkg/bin/pdksh"
        as a shell. The implementation is the following (part of the libtool 
script):

    # There may be an optional sh(1) argument at the beginning of
    # install_prog (especially on Windows NT).
    if test "$nonopt" = "$SHELL" || test "$nonopt" = /bin/sh ||
       # Allow the use of GNU shtool's install command.
       $echo "X$nonopt" | $Xsed | grep shtool > /dev/null; then
      # Aesthetically quote it.
      arg=`$echo "X$nonopt" | $Xsed -e "$sed_quote_subst"`
      case $arg in
      *[\[\~\#\^\&\*\(\)\{\}\|\;\<\>\?\'\ \     ]*|*]*)
        arg="\"$arg\""
        ;;
      esac
      install_prog="$arg "
      arg="$1"
      shift
    else
      install_prog=
      arg="$nonopt"
    fi

        In nonopt there is /usr/pkg/bin/pdksh.
        Accedently the variable SHELL is forced to /bin/sh some lines above.
        So this does not match and the number of files to installed is not
        correctly calculated. This results in an error message without calling
        the specified command line - very very bad ....
        If libtool would try the command line, it would succeed.

        I've tried to set SHELL to /usr/pkg/bin/pdksh prior starting compilation
        without any effect. (of cause I removed the work directoy for that)

        I simply fail to install gcc3-c++ till now due to the stupid libtool 
script.

        Up to now I've no idea where the information for setting SHELL=/bin/sh
        comes from.

        help ...

        remark:
          you cannot build gcc3-c with "PKGSRC_COMPILER=gcc", because this
          tries to build gcc-2.x and that does not support a 64 bit setup.
          So you need the sunpro compiler for 64-Bit setup for gcc3-c.
>How-To-Repeat:
        Setup a Solaris 2.{8,10} system to use the sunpro compiler,
        do the "modification" described above to /usr/pkg/etc/mk.conf
        and /usr/pkgsrc/lang/gcc2/Makefile.common and try to install it.
        It will install gcc correctly bur fails with g++.
>Fix:
        still not known - sorry
        The libtool scripts are not in the gcc-3.3.6.tar.bz2 file.
        They are genereated during configuration of the package.
        I've modified the libtool scripts by hand and set 
SHELL=/usr/pkg/bin/pdksh
        to get it installing, but this is no real sollution ...
        (this must be done for libstdc++ sparv9 subdir too ....)

        I'm open for additional ideas ....

        I'm not shure where the fixed setting SHELL=/bin/sh comes from.
        Perhaps this goes away if I set SHELL when building libtool-base.
        If it comes from there, than libtool-base should use the value from
        TOOLS_PLATFORM.sh for this setup. If this is a gcc3 "internal" problem,
        TOOLS_PLATFORM.sh should also be used or the libtool scripts should get
        patched to use the corresponding value.

        A simular problem happend in gcc3-f77. The "bad" SHELL setting triggers
        another error message - not excatly the same.
        But setting SHELL=/usr/pkg/bin/pdksh will fix the problem there too.
        I think there may be much more situations where libtool will fail if
        TOOLS_PLATFORM.sh is set to something different than /bin/sh.

>Unformatted: