Re: Building PCC for "tools" is broken (missing symbol __USE)- PCC bug or NetBSD source tree error?

["William D. Jones" <thor0505%comcast.net@localhost>]

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: current-users%netbsd.org@localhost
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
thor0505%comcast.net@localhost
Message sent using 'Windows Live Mail' client.