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 why if MKPCC=yes and HAVE_PCC=yes, ./build.sh still wants 
libgcc, but I'll look into it. In any case, the solution I proposed is 
simply a stopgap until PCC can compile userland.

Right now, there's at least four ways NetBSD can in theory be built:
GCC tools, GCC release
LLVM tools, LLVM release (undocumented?)
PCC tools, PCC release
EXTERNAL tools, GCC release

I figured getting GCC tools to compile PCC- again, as a stopgap solution- 
should be as simple as swapping the GCC target with the PCC target, in the 
appropriate Makefile. Since GCC can compile PCC just fine, all other 
dependencies could be left alone. However, this does not appear to be the 
case. Even after modifying bsd.mk.own and lib/Makefile, if MKPCC=yes, 
MKGCC=no, and HAVE_GCC=48 (indeed I had to move the .endif in bsd.own.mk- 
good catch), the build complains about a missing libgcc.

I suppose the only option for now is to compile both and just delete GCC 
manually after install.


-----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.