I'm not sure what happened in the past month, but suffice to say, recent
changes to the Makefiles have introduced considerable dependency hell to
building PCC... well, now's a good time as any to try to fix it, even if the
use case is special compared to GCC (personally, I wouldn't mind PCC
becoming the default compiler eventually, but that's a different story).
I'm currently running a number of dummy builds, altering mk.conf each time,
to figure out where each build chokes, and for what reason. One thing I HAVE
figured out:
-lgcc gets added to the command line in bsd.lib.mk because there is no
conditional check in bsd.own.mk that PCC is the desired target toolchain.
.if ${MKLLVM:Uno} == "yes" && ${_LIBC_COMPILER_RT.${MACHINE_ARCH}:Uno} ==
"yes"
HAVE_LIBGCC?= no
.else
HAVE_LIBGCC?= yes
.endif
Right now, I forcefully override this in mk.conf, which as far as I can tell
breaks building the GCC used for the tools directory due to
EXTERNAL_GCC_SUBDIR once again not being expanded (unrelated to the libc
expansion of EXTERNAL_GCC_SUBDIR). Probably the correct course of action is
something like this:
.if (${MKLLVM:Uno} == "yes" || ${MKPCC:Uno} == "yes") &&
${_LIBC_COMPILER_RT.${MACHINE_ARCH}:Uno} == "yes"
HAVE_LIBGCC?= no
.else
HAVE_LIBGCC?= yes
.endif
For full disclosure, I am using a shared tools directory for ALL my builds-
i386, evbarm, pcc, packard-bell 486, etc. Since NetBSD (in theory) supports
using a single tool directory for all possible targets, I'm trying to see if
I can't fix the issues by altering Makefiles before I go and purge my tools
directory. Chances are, some of the recent errors are due to not purging my
tools.
-----Original Message-----
From: Iain Hibbert
Sent: Monday, August 18, 2014 12:23 PM
To: William D. Jones
Cc: [email protected]
Subject: Re: Building PCC for "tools" is broken (missing symbol __USE)- PCC
bug or NetBSD source tree error?
On Mon, 18 Aug 2014, William D. Jones wrote:
> also, you should probably use HAVE_GCC=48 since that is the version in
> use, and the version number is checked sometimes for various features
I removed the conditional logic for MKGCC. I'll give a more complete
update
later, but believe it or not, setting HAVE_GCC=48 while MKGCC=no and
MKPCC=yes
actually causes the variable ${EXTERNAL_GCC_SUBDIR} (lib/Makefile, line 9)
to
not be expanded AT ALL when searching for libgcc to add to the list of
build
targets. This baffles me, because bs.own.mk in $NETBSD_SRC/share/mk has an
else statement which should prevent this at line 86-88, but the logic is
not
firing. Setting HAVE_GCC=4 SEEMS to solve the problem- at least, libgcc
gets
added to the list of targets and is found.
I think there is too much MKGCC conditional logic
Firstly, bsd.own.mk doesn't set EXTERNAL_GCC_SUBDIR if MKGCC=no .. the
.endif could move up a paragraph I think.
Then inside the libgcc directory there is some logic. I think the libgcc
directory should not be descended into if it is not required, rather than
descending into it and deciding we want out.
iain
--
William D. Jones
Rowan University | ECE | 2012
Member IEEE
Member Tau Beta Pi
[email protected]
Message sent using 'Windows Live Mail' client.
