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 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 because there is no conditional check in that PCC is the desired target toolchain. .if ${MKLLVM:Uno} == "yes" && ${_LIBC_COMPILER_RT.${MACHINE_ARCH}:Uno} == "yes"
HAVE_LIBGCC?=    yes

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?=    yes

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