Current-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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

I'm not sure why if MKPCC=yes and HAVE_PCC=yes, ./ 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 and lib/Makefile, if MKPCC=yes, MKGCC=no, and HAVE_GCC=48 (indeed I had to move the .endif in 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
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 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, 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.


William D. Jones
Rowan University | ECE | 2012
Member IEEE
Member Tau Beta Pi
Message sent using 'Windows Live Mail' client.

Home | Main Index | Thread Index | Old Index