head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)

[Mark Millard]

On 2018-Jul-1, at 6:34 AM, Mark Millard <marklmi at yahoo.com> wrote:

> My brain finally engaged for showing exactly what files are included
> for the gcc builds: the .meta files include that information explicitly
> (along with other files that are opened during the operation).
> 
> amd64 is as I reported, just one header file from gcc: float.h .
> 
> powerpc64 builds Lex/Lexer.cpp without defining __ALTIVEC__ and so
> is not including <altivec.h> . Building without __ALTIVEC__ might
> be an error itself but would be a workaround for the altivec.h
> file name aliasing vs. search-path problem.
> 
> . . .

Going in a different direction, what of the unchanged Makefile.inc1
code block:

.if ${WANT_COMPILER_TYPE} == gcc || \
    (defined(X_COMPILER_TYPE) && ${X_COMPILER_TYPE} == gcc)
# GCC requires -isystem and -L when using a cross-compiler.  --sysroot
# won't set header path and -L is used to ensure the base library path
# is added before the port PREFIX library path.
CD2CFLAGS+=     -isystem ${XDDESTDIR}/usr/include -L${XDDESTDIR}/usr/lib
# GCC requires -B to find /usr/lib/crti.o when using a cross-compiler
# combined with --sysroot.
CD2CFLAGS+=     -B${XDDESTDIR}/usr/lib
# Force using libc++ for external GCC.
.if defined(X_COMPILER_TYPE) && \
    ${X_COMPILER_TYPE} == gcc && ${X_COMPILER_VERSION} >= 40800
CD2CXXFLAGS+=   -isystem ${XDDESTDIR}/usr/include/c++/v1 -std=c++11 \
                -nostdinc++
.endif
.endif

Why is that pair of -isystem uses that gives the old search order
okay? Or was the block just missed? (Similarly for other options
listed above.)



Note: Locally I've reverted the -r335782 changes in order for my use
of devel/*-gcc as cross compilers to work where they used to (hopefully:
still building), restoring the historical search order for the
directories for now.



===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)