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

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

The following reply was made to PR pkg/44735; it has been noted by GNATS.

From: Wolfgang Stukenbrock <Wolfgang.Stukenbrock%nagler-company.com@localhost>
To: zingelman%gmail.com@localhost
Cc: gnats-bugs%netbsd.org@localhost, wiz%netbsd.org@localhost, 
solaris-pkg-people%netbsd.org@localhost,
        pkg-manager%netbsd.org@localhost, pkgsrc-bugs%netbsd.org@localhost, 
gnats-admin%netbsd.org@localhost,
        Wolfgang.Stukenbrock%nagler-company.com@localhost
Subject: Re: pkg/44735 (pkgsrc 2010Q4 Solaris 2.{8,10} lang/gcc3 build failed 
(libtool problem ?))
Date: Thu, 24 Mar 2011 11:55:16 +0100

 Hi,
 
 I've "TOOLS_PLATFORM.sh?= /usr/pkg/bin/pdksh" in the 
 /usr/pkg/etc/mk.conf too. It is placed there by the bootstrap process.
 
 So this would not solve the problem ...
 
 A build of lang/gcc44 failed on my Solaris 8 system during build of some 
 other packages required by gcc44. Accedently it is also not possible to 
 compile all required things of gcc44 with sunstudio compiler. (neither 
 on 5.8 nor 5.10) So I would need gcc3 (or similar) for this (?!?!?) and 
 here I revert to the old gcc3 ...
 I prefer the "original" compiler from the vendor for compilation 
 whereever possible. GCC on SPARC was not "optimal" in the past and I 
 have no time to search "problems" due to "bad" code generation for some 
 SPARC chips.
 Up to now I've found some other "stupid" things that are effects of 
 libtool while trying to build cups on 5.8.
 
 When I switch to gcc3 for compilation, I run into problems with libtool 
 again, because libtool was build with sunstudio and there are some 
 imcompartible options that are hardcoded into /usr/pkg/bin/libtool ...
 The main problem here is, that libtool has no support (till now) for 
 more than one compiler setup. It would be realy great improvement if 
 libtool would support different compilers in one installation depending 
 on "whatever" option, compiler name analyses or environment setting.
 
 First -G does not work with gcc, so the following line is required to 
 fix the option:
 WRAPPER_TRANSFORM_CMDS+= opt:-G:-shared
 There are some -G<num> options for some architectures in gcc, but I hope 
 this does not hurt - at least for me it works for now.
 
 The next problem is that sunstudio requires CC to be called with -xar to 
 build .a files from c++ sources. G++ never heard of this ...
 This is more problematic, but can be worked around be the following:
 
 # need to work around a big libtool problem when building AR files from c++
 # remark: WRAPPER_TMPDIR is still not set here - but we must define a new
 #         rule ..
 #         do not know how to add rules "at the end" of the Makefiles here
 #         so we need to assume the default setup here
 _WRAP_ARG_PP.CXX=       ${.CURDIR}/work/.wrapper/tmp/arg-pp.CXX
 # remark: we are defining a target here and this is the first one
 #         accedently we cannot specify a default all: target, because
 #         this target will only be defined in bsd.pkg.mk if not already a
 #         target. For unknown reasons (till now) calling bmake without any
 #         arguments seems to build the all target anyway.
 
 ${_WRAP_ARG_PP.CXX}:
          ${RUN} ${MKDIR} ${.TARGET:H}
          ${RUN} ${ECHO} 'case $$arg in' 
                          >  ${.TARGET}
          ${RUN} ${ECHO} '-xar) cmd="/usr/ccs/bin/ar cru"; argmatch=yes; 
 xxx_kill_args=1'        >> ${.TARGET}
          ${RUN} ${ECHO} '# need to kill the following -o option - we 
 know that it is there ...' >> ${.TARGET}
          ${RUN} ${ECHO} '      pop_queue argbuf arg' 
                          >> ${.TARGET}
          ${RUN} ${ECHO} '      ;;' 
                          >> ${.TARGET}
          ${RUN} ${ECHO} '-*)   if [ -n "$$xxx_kill_args" ]; then' 
                           >> ${.TARGET}
          ${RUN} ${ECHO} '# need to kill the current argument in case it 
 is the last one ...'    >> ${.TARGET}
          ${RUN} ${ECHO} '        arg=""; argmatch=yes; do_transform=no' 
                          >> ${.TARGET}
          ${RUN} ${ECHO} '      fi' 
                          >> ${.TARGET}
          ${RUN} ${ECHO} '      ;;' 
                          >> ${.TARGET}
          ${RUN} ${ECHO} 'esac' 
                          >> ${.TARGET}
 
 This assumes that libtool will generate a command line like this:
 g++ -xar -o libX.a f1.o f2.o ... fn.o -m64 -L/... -L/....
 It will build the following command line from that:
 "/usr/ccs/bin/ar cru libX.a f1.o f2.o ... fn.o"
 I hope that no package will ever generate -xar without -o libX.a behind, 
 because I simply dropt the next option at the moment directly. This can 
 be removed in this version now - I'm just seeing - becau may be nothing 
 in front of -xar ... For now it works for me ...
 
 I've placed this in my /usr/pkg/etc/mk.conf because I do not know what 
 packages all will need it if compilation with sunstudio is not possible 
 due to syntax problems in the c++ sources.
 If you know a way to define targets that are not directly processed in 
 mk.conf by bmake, I'm very interested! Is there a way to specify some 
 additional include files to be included last or at the end of 
 bsd.pkg.mk? That would be a way to solve the problem.
 
 I will send a new bug report about poppler in a few minutes, because it 
 will not compile on 5.8 due to missing fmin/fmax function on 5.8.
 (This is the current state I've reached with my build ....)
 
 Best regards
 
 W. Stukenbrock
 
 Tim Zingelman wrote:
 
 > Thank you for the very detailed analysis.
 > 
 > I find that on my solaris systems, /usr/pkg/bin/libtool contains
 > SHELL="/usr/pkg/bin/pdksh", and my
 > /usr/pkg/etc/mk.conf contains TOOLS_PLATFORM.sh?= /usr/pkg/bin/pdksh
 > so I would guess that rebuilding your libtool package after setting
 > TOOLS_PLATFORM.sh may resolve that part of your problem.  Is that
 > something you could try?
 > 
 > In addition you might try building the lang/gcc44 rather than the very
 > old lang/gcc3... also solaris 10 may have a usable gcc in /usr/sfw/bin
 > that would be easier than building the pkgsrc version with the sun
 > compiler?
 > 
 > I don't use the sun compiler in production, and don't currently have a
 > working test system with sunstudio installed, so I can't comment on
 > the rest.
 >