On Aug 12, 2016, at 12:54 PM, matthew green wrote: > Thor Lancelot Simon writes: >> On Thu, Aug 11, 2016 at 04:05:06PM +0100, Robert Swindells wrote: >>> >>>> 2) /usr/bin/cc: >>>> Undefined symbols for architecture x86_64: "_iconv" >>>> in external/gpl3/gcc/usr.bin/backend >>> >>> This should be in libc. >> >> For what value of "should"? _iconv is in the implementation-defined >> namespace. >> >> It's curious that this doesn't break the tools build, and doesn't >> prevent using the built tools to build a kernel! If this can break >> the cross-build of the target compiler, I think we must have suddenly >> sprouted a rather serious instance of host/target confusion. > > this fails building the native gcc, which requires a bunch of host > tools to run. going on your following post, there is a problem > with genmatch. i don't have access to any osx to test, so i'm not > sure where to start looking. there aren't too many rules used in > the creation of "genmatch" binary - can you run "make cleandir" > in usr.bin/backend/ and then "make MAKEVERBOSE=2 genmatch", and > post all the commands run? there probably will be a configure > run in here, and perhaps the output of it also matters. > > > .mrg. > >
I still have a log from the maybe-similar failure on freebsd: https://gist.github.com/mfplass/98801ea2ab2cd3d5abd92faa3c47ab1c It, too, is trying to build genmatch. The config.status for host-libcpp is at https://gist.github.com/mfplass/6a75e12339bc97223854953fee1fa9fc - Michael
