NetBSD Problem Report #44735
From Wolfgang.Stukenbrock@nagler-company.com Thu Mar 17 13:36:52 2011
Return-Path: <Wolfgang.Stukenbrock@nagler-company.com>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
by www.NetBSD.org (Postfix) with ESMTP id 4E65C63B995
for <gnats-bugs@gnats.NetBSD.org>; Thu, 17 Mar 2011 13:36:52 +0000 (UTC)
Message-Id: <20110317133641.4C0781E80CE@test-s0.nagler-company.com>
Date: Thu, 17 Mar 2011 14:36:41 +0100 (CET)
From: Wolfgang.Stukenbrock@nagler-company.com
Reply-To: Wolfgang.Stukenbrock@nagler-company.com
To: gnats-bugs@gnats.NetBSD.org
Subject: pkgsrc 2010Q4 Solaris 2.{8,10} lang/gcc3 build failed (libtool problem ?)
X-Send-Pr-Version: 3.95
>Number: 44735
>Category: pkg
>Synopsis: pkgsrc 2010Q4 Solaris 2.{8,10} lang/gcc3 build failed (libtool problem ?)
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: solaris-pkg-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Thu Mar 17 13:40:00 +0000 2011
>Last-Modified: Mon Mar 28 08:20:02 +0000 2011
>Originator: Dr. Wolfgang Stukenbrock
>Release: NetBSD 4.0
>Organization:
Dr. Nagler & Company GmbH
>Environment:
Solaris 8, Solaris 10
>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.
>Release-Note:
>Audit-Trail:
[20110327 shattered] edited Environment: field
Responsible-Changed-From-To: pkg-manager->solaris-pkg-people
Responsible-Changed-By: wiz@NetBSD.org
Responsible-Changed-When: Thu, 17 Mar 2011 14:22:45 +0000
Responsible-Changed-Why:
Solaris pkgsrc problem.
From: Tim Zingelman <zingelman@gmail.com>
To: gnats-bugs@netbsd.org
Cc: wiz@netbsd.org, solaris-pkg-people@netbsd.org, pkg-manager@netbsd.org,
pkgsrc-bugs@netbsd.org, gnats-admin@netbsd.org,
Wolfgang.Stukenbrock@nagler-company.com
Subject: Re: pkg/44735 (pkgsrc 2010Q4 Solaris 2.{8,10} lang/gcc3 build failed
(libtool problem ?))
Date: Wed, 23 Mar 2011 11:57:44 -0500
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.
From: Wolfgang Stukenbrock <Wolfgang.Stukenbrock@nagler-company.com>
To: zingelman@gmail.com
Cc: gnats-bugs@netbsd.org, wiz@netbsd.org, solaris-pkg-people@netbsd.org,
pkg-manager@netbsd.org, pkgsrc-bugs@netbsd.org, gnats-admin@netbsd.org,
Wolfgang.Stukenbrock@nagler-company.com
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.
>
From: Tim Zingelman <zingelman@gmail.com>
To: gnats-bugs@netbsd.org
Cc: Wolfgang Stukenbrock <Wolfgang.Stukenbrock@nagler-company.com>, solaris-pkg-people@netbsd.org,
gnats-admin@netbsd.org, pkgsrc-bugs@netbsd.org
Subject: Re: pkg/44735 (pkgsrc 2010Q4 Solaris 2.{8,10} lang/gcc3 build failed
(libtool problem ?))
Date: Fri, 25 Mar 2011 10:03:52 -0500
On Thu, Mar 24, 2011 at 6:00 AM, Wolfgang Stukenbrock
<Wolfgang.Stukenbrock@nagler-company.com> wrote:
> The following reply was made to PR pkg/44735; it has been noted by GNATS.
>
> =A0I've "TOOLS_PLATFORM.sh?=3D /usr/pkg/bin/pdksh" in the
> =A0/usr/pkg/etc/mk.conf too. It is placed there by the bootstrap process.
>
I guess I do not understand then how your libtool comes to contain
SHELL=3D/bin/sh and mine has the correct SHELL=3D/usr/pkg/bin/pdksh
> =A0When I switch to gcc3 for compilation, I run into problems with libtoo=
l
> =A0again, because libtool was build with sunstudio and there are some
> =A0imcompartible options that are hardcoded into /usr/pkg/bin/libtool ...
> =A0The main problem here is, that libtool has no support (till now) for
> =A0more than one compiler setup. It would be realy great improvement if
> =A0libtool would support different compilers in one installation dependin=
g
> =A0on "whatever" option, compiler name analyses or environment setting.
I think this should be fixed in the compiler specific transforms found
in pkgsrc/mk/wrapper/* the idea being that based on the compiler (or
other tool) in use, all args are converted to match what is needed. I
am aware that these are currently incomplete, but have not understood
the entire infrastructure sufficiently yet to propose required fixes.
> =A0First -G does not work with gcc, so the following line is required to
> =A0fix the option:
> =A0WRAPPER_TRANSFORM_CMDS+=3D opt:-G:-shared
> =A0There are some -G<num> options for some architectures in gcc, but I ho=
pe
> =A0this does not hurt - at least for me it works for now.
>
> =A0The next problem is that sunstudio requires CC to be called with -xar =
to
> =A0build .a files from c++ sources. G++ never heard of this ...
> =A0This is more problematic, but can be worked around be the following:
I'm not sure I follow the complex solution you suggest, but if the
only requirement is to remove the -xar argument, then
WRAPPER_TRANSFORM_CMDS+=3D rm:-xar would do that for you.
I'm not a make expert, so perhaps someone else could better answer the
other questions.
From: Wolfgang Stukenbrock <Wolfgang.Stukenbrock@nagler-company.com>
To: zingelman@gmail.com
Cc: gnats-bugs@netbsd.org,
Wolfgang Stukenbrock <Wolfgang.Stukenbrock@nagler-company.com>,
solaris-pkg-people@netbsd.org, gnats-admin@netbsd.org,
pkgsrc-bugs@netbsd.org
Subject: Re: pkg/44735 (pkgsrc 2010Q4 Solaris 2.{8,10} lang/gcc3 build failed (libtool problem ?))
Date: Mon, 28 Mar 2011 10:17:57 +0200
Hi again,
just to clarify the "main" problem again to avoid possible confusion.
It is not /usr/pkg/bin/libtool where the wrong shell is in.
It is a generated libtool script inside of the gcc3 tree.
I do not track down till now how it is generated. And the problem only
comes up, if the last argument to install is not a directory.
Last "my" current "final" state of mk.conf setup that now seems to
compile everything correctly. I know that is not 100% related to the
original cause of the PR, but it belongs into the same category from my
point of view.
When useing sunstudio compiler most times and use gcc(3) only for
packages where syntax problems (or simular) occur. the following
"workaround" work for gcc3 and everything required for samba.
(see some additional bug reports on "bad" sources in some packages too.)
I introduce a new make variable to switch between the compilers: NC_PKG_GCC
I set this in the Makefile or Makefile.common for the packages that
cannot be build with sunstudio for whatever resons.
mk.conf contents for building packages in pkgsrc.
In addition to the currently reported -G option, gcc doesn't understand
-library=... that needs to be eliminated.
Than "-Qoption ld -R..." need to be transformed to either -R... or
-Wl,-R... (I transform it to -R.... below)
When -xar is specified we need to change the command from CC to AR and
eliminate any additional options that are placed there by libtool from
the command line (some -L.., -m64, ...)
remark: this is no completet analyses of the options, I just fixed the
one that keep the sutff from compiling/installing.
The currently available support by the wrappers that can be controlled
by setting some variables in the makefile is not abled to support the
required modification for -xar and -Qoption. The support to specify
additional wrapper script generation code looks imcomplete to me. but
perhaps I've haven't got the main point till now.
Now the mk.conf script part for pkgsrc-builds:
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
WRAPPER_TRANSFORM_CMDS+= opt:-G:-shared rm:-library=.*
_WRAP_ARG_PP.CXX= ${.CURDIR}/work/.wrapper/tmp/arg-pp.CXX
${_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} '-Qoption) argmatch=yes'
>> ${.TARGET}
${RUN} ${ECHO} '# need to kill the following ld argument - we
know that it is there ...' >> ${.TARGET}
${RUN} ${ECHO} ' pop_queue argbuf arg; 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}
.else
PKGSRC_COMPILER= sunpro
CC= cc
CXX= CC
CPP= ${CC} -E
SUNWSPROBASE= /opt/SUNWspro
.endif
MACHINE_GNU_PLATFORM= sparc64-sun-solaris2
SPARC_TARGET_ARCH= sparcv9
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 to avoid possible Solaris tar incomparbilities with
"latest" gnutar stuff
TOOLS_PLATFORM.tar?= /usr/pkg/bin/bsdtar
Perhaps something of this will find it's way into the documentation for
The settings for MACHINE_GNU_PLATFORM and SPARC_TARGET_ARCH should be
generated by the bootstrap process if ABI=64 is used. It is needed by
some packages in a "gcc only" setup too. And The evaluated defaults for
theese variables are simply wrong resulting in build errors in the packages.
Best regards
W. Stukenbrock
Tim Zingelman wrote:
> On Thu, Mar 24, 2011 at 6:00 AM, Wolfgang Stukenbrock
> <Wolfgang.Stukenbrock@nagler-company.com> wrote:
>
>>The following reply was made to PR pkg/44735; it has been noted by GNATS.
>>
>> 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.
>>
>>
>
> I guess I do not understand then how your libtool comes to contain
> SHELL=/bin/sh and mine has the correct SHELL=/usr/pkg/bin/pdksh
>
>
>> 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.
>>
>
> I think this should be fixed in the compiler specific transforms found
> in pkgsrc/mk/wrapper/* the idea being that based on the compiler (or
> other tool) in use, all args are converted to match what is needed. I
> am aware that these are currently incomplete, but have not understood
> the entire infrastructure sufficiently yet to propose required fixes.
>
>
>> 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:
>>
>
> I'm not sure I follow the complex solution you suggest, but if the
> only requirement is to remove the -xar argument, then
> WRAPPER_TRANSFORM_CMDS+= rm:-xar would do that for you.
>
> I'm not a make expert, so perhaps someone else could better answer the
> other questions.
>
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home