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

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

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.