Re: I've submitted 207175 for a clang 3.8.0 va_list handling problem for powerpc
On 02/14/16 14:34, Mark Millard wrote: clang's code base is not familiar material for me nor do I have solid reference material for the FreeBSD TARGET_ARCH=powerpc ABI rules so the below has my guess work involved. The following code appears to have hard wired a global, unvarying constant (8) into the test for picking UsingRegs vs. UsingOverflow. For reference, we use the standard ELF ABI (https://uclibc.org/docs/psABI-ppc.pdf). -Nathan ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: /usr/src/Makefile.inc1 vs. buildworld finding include files: a problem for some contexts?
A top post as I figured out what is going on:
My original src.conf had a bad "optimization" where I had been thinking that
since I had a working compiler that was not being updated with new source code
that I could avoid the time to rebuild it during the bootstrap:
WITHOUT_GCC_BOOTSTRAP=
But this makes the default include/library paths wrong for buildworld and the
like and so requires them to be enforced on the command line. The build
environment is not set up to automatically do that in such cases.
So I had wondered out of bounds.
===
Mark Millard
markmi at dsl-only.net
On 2016-Feb-14, at 12:35 PM, Mark Millard wrote:
>
> On 2016-Feb-14, at 12:16 PM, Warner Losh wrote:
>>
>> On Sun, Feb 14, 2016 at 12:21 PM, Mark Millard wrote:
>> Is buildworld supposed to use /usr/include's area for finding files by
>> default? (I'm not talking of ${WORLDTMP}/usr/include but of just
>> /usr/include.)
>>
>> Yes, but only though the end of the bootstrap phase.
>>
>> It does use /usr/include's area for some contexts: self-hosted builds
>> without a special XCC full path (e.g., an implicit TARGET_ARCH=powerpc on a
>> powerpc host using gcc 4.2.1 without an explicit XCC assignment that also
>> directs it to gcc 4.2.1 via a full path).
>>
>> /usr/src/Makefile.inc1 has the following sort of logic:
>>
>>> .if ${XCC:N${CCACHE_BIN}:M/*}
>> . . .
>>> .if defined(X_COMPILER_TYPE) && ${X_COMPILER_TYPE} == gcc
>>> XCFLAGS+= -isystem ${WORLDTMP}/usr/include -L${WORLDTMP}/usr/lib
>>> XCXXFLAGS+= -I${WORLDTMP}/usr/include/c++/v1 -std=gnu++11
>>> -L${WORLDTMP}/../lib/libc++
>> . . .
>>> .else
>> . . .
>>> .endif
>>> XCFLAGS+= --sysroot=${WORLDTMP} ${BFLAGS}
>>> XCXXFLAGS+= --sysroot=${WORLDTMP} ${BFLAGS}
>>> .else
>>> .if defined(CROSS_BINUTILS_PREFIX) && exists(${CROSS_BINUTILS_PREFIX})
>>> BFLAGS+=-B${CROSS_BINUTILS_PREFIX}
>>> XCFLAGS+= ${BFLAGS}
>>> XCXXFLAGS+= ${BFLAGS}
>>> .endif
>>> .endif # ${XCC:M/*}
>>
>> For contexts without the -isystem and/or --sysroot in XCFLAGS . . .
>>
>> Is it appropriate to submit bug reports for buildworld getting include files
>> from /usr/include instead of from ${WORLDTMP} or from /usr/src areas?
>>
>> If it is during the build everything phase, yes it is a build bug. If it is
>> during the bootstrap phase, then yes, it is expected we use the host, but
>> there's some incompatibility in bootstrapping we need to fix.
>>
>> This tends to be noticed when something like the following. . .
>>
>>> # svnlite update -r295453 /usr/src
>>> # env __MAKE_CONF=/root/src.configs/make.conf
>>> SRC_ENV_CONF=/root/src.configs/src.conf.powerpc-gcc421.powerpc-host
>>> MAKEOBJDIRPREFIX=/usr/obj/gcc421/powerpc.powerpc make -j 6 buildworld
>>> buildkernel
>>
>> ends up with compile errors from using some older /usr/include header files
>> that are no longer sufficient to allow compilation.
>>
>> I recently had a couple of examples where the cc command in the script
>> output file for the failing compiles showed no -I , no -isystem , no
>> --sysroot , nothing that would have allowed it to even potentially avoid
>> /usr/include (old file) use. The Makefile*'s involved had no
>> CFLAGS+=SOMETHING_DIRECTING_INCLUDE_SEARCH .
>>
>> (Some types of header changes might not stop a build but might make the
>> build result wrong without much explicit notification. I'd prefer to avoid
>> such as well.)
>>
>> I expect that there are analogous points/questions for finding libraries.
>>
>> Specific examples would be most welcome.
>>
>> Warner
>
> I had submitted the following bug reports for the two recent examples that
> prompted my question. . .
>
>
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207147 for:
>
> In file included from /usr/src/lib/libmemstat/memstat_uma.c:37:
> /usr/include/vm/uma_int.h:310: error: field 'uz_maxaction' has incomplete type
>
>
>
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207148 for:
>
> /usr/src/bin/pkill/pkill.c:353: error: 'P_KPROC' undeclared (first use in
> this function)
>
>
>
> In both cases the /usr/include vintage file was in use after my update of
> /usr/src to -r295453. In both cases the "cc" command had no -I , no -sysroot
> , and no -isystem to direct the searching for the header file.
>
> ===
> Mark Millard
> markmi at dsl-only.net
>
>
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: I've submitted 207175 for a clang 3.8.0 va_list handling problem for powerpc
On 2016-Feb-14, at 11:29 AM, Roman Divacky wrote:
>
> Fwiw, the code to handle the vaarg is in
> tools/clang/lib/CodeGen/TargetInfo.cpp:PPC32_SVR4_ABIInfo::EmitVAArg()
>
> You can take a look to see whats wrong.
>
> On Sat, Feb 13, 2016 at 07:03:29PM -0800, Mark Millard wrote:
>> I've isolated another clang 3.8.0 TARGET_ARCH=powerpc SEGV problem that
>> shows up for using clang 3.8.0 to buildworld/installworld for powerpc.
>>
>>> ls -l -n /
>>
>> gets a SEGV. As listed in
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207175 ( and
>> https://llvm.org/bugs/show_bug.cgi?id=26605 ) the following simplified
>> program also gets the SEGV on powerpc:
>>
>>> #include // for va_list, va_start, va_arg, va_end
>>> #include // for intmax_t
>>>
>>> intmax_t
>>> va_test (char *s, ...)
>>> {
>>>va_list vap;
>>>
>>>va_start(vap, s);
>>>
>>>char*t0 = va_arg(vap, char*);
>>>unsigned int o0 = va_arg(vap, unsigned int);
>>>int c0 = va_arg(vap, int);
>>>unsigned int u0 = va_arg(vap, unsigned int);
>>>int c1 = va_arg(vap, int);
>>>char * t1 = va_arg(vap, char*);
>>>
>>>intmax_t j0 = va_arg(vap, intmax_t); // This spans into
>>> overflow_arg_area.
>>>
>>>int c2 = va_arg(vap, int); // A copy was put in the
>>> // overflow_arg_area because of
>>> the
>>> // above.
>>> // But this tries to extract
>>> from the
>>> // last 4 bytes of the
>>> reg_save_area.
>>> // It does not increment the
>>> // overflow_arg_area position
>>> pointer
>>> // past the copy that is there.
>>>
>>>char * t2 = va_arg(vap, char*);// The lack of increment before
>>> makes
>>> // this extraction off by 4
>>> bytes.
>>>
>>>char t2fc = *t2; // <<< This gets SEGV. t2 actually got what
>>> should be
>>> // the c2 value.
>>>
>>>intmax_t j1 = va_arg(vap, intmax_t);
>>>
>>>va_end(vap);
>>>
>>>return (intmax_t) ((s-t2)+(t0-t1)+o0+u0+j0+j1+c0+c1+c2+t2fc);
>>>// Avoid any optimize-away for lack of use.
>>> }
>>>
>>> int main(void)
>>> {
>>>char s[1025] = "test string for this";
>>>
>>>char*t0 = s + 5;
>>>unsigned int o0 = 3;
>>>int c0 = 1;
>>>unsigned int u0 = 1;
>>>int c1 = 3;
>>>char * t1 = s + 12;
>>>intmax_t j0 = 314159265358979323;
>>>int c2 = 4;
>>>char * t2 = s + 16;
>>>intmax_t j1 = ~314159265358979323;
>>>
>>>intmax_t result = va_test(s,t0,o0,c0,u0,c1,t1,j0,c1,t2,j1);
>>>
>>>return (int) (result - (intmax_t)
>>> ((s-t2)+(t0-t1)+o0+u0+j0+j1+c0+c1+c2+*t2));
>>>// Avoid any optimize-away for lack of use.
>>> }
>>
>>
>>
>> ===
>> Mark Millard
>> markmi at dsl-only.net
>>
>> ___
>> freebsd-toolchain@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
>> To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
clang's code base is not familiar material for me nor do I have solid reference
material for the FreeBSD TARGET_ARCH=powerpc ABI rules so the below has my
guess work involved.
The following code appears to have hard wired a global, unvarying constant (8)
into the test for picking UsingRegs vs. UsingOverflow.
> llvm::Value *NumRegs = Builder.CreateLoad(NumRegsAddr, "numUsedRegs");
. . .
> llvm::Value *CC =
> Builder.CreateICmpULT(NumRegs, Builder.getInt8(8), "cond");
>
> llvm::BasicBlock *UsingRegs = CGF.createBasicBlock("using_regs");
> llvm::BasicBlock *UsingOverflow = CGF.createBasicBlock("using_overflow");
> llvm::BasicBlock *Cont = CGF.createBasicBlock("cont");
>
> Builder.CreateCondBr(CC, UsingRegs, UsingOverflow);
. . .
> // Case 1: consume registers.
> Address RegAddr = Address::invalid();
> {
. . .
> // Increase the used-register count.
> NumRegs =
> Builder.CreateAdd(NumRegs,
> Builder.getInt8((isI64 || (isF64 && IsSoftFloatABI))
> ? 2 : 1));
> Builder.CreateStore(NumRegs, NumRegsAddr);. . .
. . .
> }
>
> // Case 2: consume space in the overflow area.
> Address MemAddr = Address::invalid();
> {
. . . (no adjustments to NumRegs) . . .
If so the means of counting NumRegs (a.k.a. gpr) then needs to take into
account an allocated but unused last UsingRegs "slot" sometimes. Imagine. . .
r3, r4, r5, r6, r7, r8, r9 in use already so r10 is the last possible
"UsingRegs" context.
(0 1 2 3 4 5 6, leaving r10 as position 7, the last < 8 value)
Then the next two arguments are a 8 b
Re: /usr/src/Makefile.inc1 vs. buildworld finding include files: a problem for some contexts?
On 2016-Feb-14, at 12:16 PM, Warner Losh wrote:
>
> On Sun, Feb 14, 2016 at 12:21 PM, Mark Millard wrote:
> Is buildworld supposed to use /usr/include's area for finding files by
> default? (I'm not talking of ${WORLDTMP}/usr/include but of just
> /usr/include.)
>
> Yes, but only though the end of the bootstrap phase.
>
> It does use /usr/include's area for some contexts: self-hosted builds without
> a special XCC full path (e.g., an implicit TARGET_ARCH=powerpc on a powerpc
> host using gcc 4.2.1 without an explicit XCC assignment that also directs it
> to gcc 4.2.1 via a full path).
>
> /usr/src/Makefile.inc1 has the following sort of logic:
>
> > .if ${XCC:N${CCACHE_BIN}:M/*}
> . . .
> > .if defined(X_COMPILER_TYPE) && ${X_COMPILER_TYPE} == gcc
> > XCFLAGS+= -isystem ${WORLDTMP}/usr/include -L${WORLDTMP}/usr/lib
> > XCXXFLAGS+= -I${WORLDTMP}/usr/include/c++/v1 -std=gnu++11
> > -L${WORLDTMP}/../lib/libc++
> . . .
> > .else
> . . .
> > .endif
> > XCFLAGS+= --sysroot=${WORLDTMP} ${BFLAGS}
> > XCXXFLAGS+= --sysroot=${WORLDTMP} ${BFLAGS}
> > .else
> > .if defined(CROSS_BINUTILS_PREFIX) && exists(${CROSS_BINUTILS_PREFIX})
> > BFLAGS+=-B${CROSS_BINUTILS_PREFIX}
> > XCFLAGS+= ${BFLAGS}
> > XCXXFLAGS+= ${BFLAGS}
> > .endif
> > .endif # ${XCC:M/*}
>
> For contexts without the -isystem and/or --sysroot in XCFLAGS . . .
>
> Is it appropriate to submit bug reports for buildworld getting include files
> from /usr/include instead of from ${WORLDTMP} or from /usr/src areas?
>
> If it is during the build everything phase, yes it is a build bug. If it is
> during the bootstrap phase, then yes, it is expected we use the host, but
> there's some incompatibility in bootstrapping we need to fix.
>
> This tends to be noticed when something like the following. . .
>
> > # svnlite update -r295453 /usr/src
> > # env __MAKE_CONF=/root/src.configs/make.conf
> > SRC_ENV_CONF=/root/src.configs/src.conf.powerpc-gcc421.powerpc-host
> > MAKEOBJDIRPREFIX=/usr/obj/gcc421/powerpc.powerpc make -j 6 buildworld
> > buildkernel
>
> ends up with compile errors from using some older /usr/include header files
> that are no longer sufficient to allow compilation.
>
> I recently had a couple of examples where the cc command in the script output
> file for the failing compiles showed no -I , no -isystem , no --sysroot ,
> nothing that would have allowed it to even potentially avoid /usr/include
> (old file) use. The Makefile*'s involved had no
> CFLAGS+=SOMETHING_DIRECTING_INCLUDE_SEARCH .
>
> (Some types of header changes might not stop a build but might make the build
> result wrong without much explicit notification. I'd prefer to avoid such as
> well.)
>
> I expect that there are analogous points/questions for finding libraries.
>
> Specific examples would be most welcome.
>
> Warner
I had submitted the following bug reports for the two recent examples that
prompted my question. . .
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207147 for:
In file included from /usr/src/lib/libmemstat/memstat_uma.c:37:
/usr/include/vm/uma_int.h:310: error: field 'uz_maxaction' has incomplete type
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207148 for:
/usr/src/bin/pkill/pkill.c:353: error: 'P_KPROC' undeclared (first use in this
function)
In both cases the /usr/include vintage file was in use after my update of
/usr/src to -r295453. In both cases the "cc" command had no -I , no -sysroot ,
and no -isystem to direct the searching for the header file.
===
Mark Millard
markmi at dsl-only.net
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: /usr/src/Makefile.inc1 vs. buildworld finding include files: a problem for some contexts?
On Sun, Feb 14, 2016 at 12:21 PM, Mark Millard wrote:
> Is buildworld supposed to use /usr/include's area for finding files by
> default? (I'm not talking of ${WORLDTMP}/usr/include but of just
> /usr/include.)
>
Yes, but only though the end of the bootstrap phase.
> It does use /usr/include's area for some contexts: self-hosted builds
> without a special XCC full path (e.g., an implicit TARGET_ARCH=powerpc on a
> powerpc host using gcc 4.2.1 without an explicit XCC assignment that also
> directs it to gcc 4.2.1 via a full path).
>
> /usr/src/Makefile.inc1 has the following sort of logic:
>
> > .if ${XCC:N${CCACHE_BIN}:M/*}
> . . .
> > .if defined(X_COMPILER_TYPE) && ${X_COMPILER_TYPE} == gcc
> > XCFLAGS+= -isystem ${WORLDTMP}/usr/include -L${WORLDTMP}/usr/lib
> > XCXXFLAGS+= -I${WORLDTMP}/usr/include/c++/v1 -std=gnu++11
> -L${WORLDTMP}/../lib/libc++
> . . .
> > .else
> . . .
> > .endif
> > XCFLAGS+= --sysroot=${WORLDTMP} ${BFLAGS}
> > XCXXFLAGS+= --sysroot=${WORLDTMP} ${BFLAGS}
> > .else
> > .if defined(CROSS_BINUTILS_PREFIX) && exists(${CROSS_BINUTILS_PREFIX})
> > BFLAGS+=-B${CROSS_BINUTILS_PREFIX}
> > XCFLAGS+= ${BFLAGS}
> > XCXXFLAGS+= ${BFLAGS}
> > .endif
> > .endif # ${XCC:M/*}
>
> For contexts without the -isystem and/or --sysroot in XCFLAGS . . .
>
> Is it appropriate to submit bug reports for buildworld getting include
> files from /usr/include instead of from ${WORLDTMP} or from /usr/src areas?
>
If it is during the build everything phase, yes it is a build bug. If it is
during the bootstrap phase, then yes, it is expected we use the host, but
there's some incompatibility in bootstrapping we need to fix.
> This tends to be noticed when something like the following. . .
>
> > # svnlite update -r295453 /usr/src
> > # env __MAKE_CONF=/root/src.configs/make.conf
> SRC_ENV_CONF=/root/src.configs/src.conf.powerpc-gcc421.powerpc-host
> MAKEOBJDIRPREFIX=/usr/obj/gcc421/powerpc.powerpc make -j 6 buildworld
> buildkernel
>
> ends up with compile errors from using some older /usr/include header
> files that are no longer sufficient to allow compilation.
>
> I recently had a couple of examples where the cc command in the script
> output file for the failing compiles showed no -I , no -isystem , no
> --sysroot , nothing that would have allowed it to even potentially avoid
> /usr/include (old file) use. The Makefile*'s involved had no
> CFLAGS+=SOMETHING_DIRECTING_INCLUDE_SEARCH .
>
> (Some types of header changes might not stop a build but might make the
> build result wrong without much explicit notification. I'd prefer to avoid
> such as well.)
>
> I expect that there are analogous points/questions for finding libraries.
>
Specific examples would be most welcome.
Warner
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: I've submitted 207175 for a clang 3.8.0 va_list handling problem for powerpc
Fwiw, the code to handle the vaarg is in
tools/clang/lib/CodeGen/TargetInfo.cpp:PPC32_SVR4_ABIInfo::EmitVAArg()
You can take a look to see whats wrong.
On Sat, Feb 13, 2016 at 07:03:29PM -0800, Mark Millard wrote:
> I've isolated another clang 3.8.0 TARGET_ARCH=powerpc SEGV problem that shows
> up for using clang 3.8.0 to buildworld/installworld for powerpc.
>
> > ls -l -n /
>
> gets a SEGV. As listed in
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207175 ( and
> https://llvm.org/bugs/show_bug.cgi?id=26605 ) the following simplified
> program also gets the SEGV on powerpc:
>
> > #include // for va_list, va_start, va_arg, va_end
> > #include // for intmax_t
> >
> > intmax_t
> > va_test (char *s, ...)
> > {
> > va_list vap;
> >
> > va_start(vap, s);
> >
> > char*t0 = va_arg(vap, char*);
> > unsigned int o0 = va_arg(vap, unsigned int);
> > int c0 = va_arg(vap, int);
> > unsigned int u0 = va_arg(vap, unsigned int);
> > int c1 = va_arg(vap, int);
> > char * t1 = va_arg(vap, char*);
> >
> > intmax_t j0 = va_arg(vap, intmax_t); // This spans into
> > overflow_arg_area.
> >
> > int c2 = va_arg(vap, int); // A copy was put in the
> > // overflow_arg_area because
> > of the
> > // above.
> > // But this tries to extract
> > from the
> > // last 4 bytes of the
> > reg_save_area.
> > // It does not increment the
> > // overflow_arg_area position
> > pointer
> > // past the copy that is there.
> >
> > char * t2 = va_arg(vap, char*);// The lack of increment
> > before makes
> > // this extraction off by 4
> > bytes.
> >
> > char t2fc = *t2; // <<< This gets SEGV. t2 actually got what
> > should be
> > // the c2 value.
> >
> > intmax_t j1 = va_arg(vap, intmax_t);
> >
> > va_end(vap);
> >
> > return (intmax_t) ((s-t2)+(t0-t1)+o0+u0+j0+j1+c0+c1+c2+t2fc);
> > // Avoid any optimize-away for lack of use.
> > }
> >
> > int main(void)
> > {
> > char s[1025] = "test string for this";
> >
> > char*t0 = s + 5;
> > unsigned int o0 = 3;
> > int c0 = 1;
> > unsigned int u0 = 1;
> > int c1 = 3;
> > char * t1 = s + 12;
> > intmax_t j0 = 314159265358979323;
> > int c2 = 4;
> > char * t2 = s + 16;
> > intmax_t j1 = ~314159265358979323;
> >
> > intmax_t result = va_test(s,t0,o0,c0,u0,c1,t1,j0,c1,t2,j1);
> >
> > return (int) (result - (intmax_t)
> > ((s-t2)+(t0-t1)+o0+u0+j0+j1+c0+c1+c2+*t2));
> > // Avoid any optimize-away for lack of use.
> > }
>
>
>
> ===
> Mark Millard
> markmi at dsl-only.net
>
> ___
> freebsd-toolchain@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
> To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
/usr/src/Makefile.inc1 vs. buildworld finding include files: a problem for some contexts?
Is buildworld supposed to use /usr/include's area for finding files by default?
(I'm not talking of ${WORLDTMP}/usr/include but of just /usr/include.)
It does use /usr/include's area for some contexts: self-hosted builds without a
special XCC full path (e.g., an implicit TARGET_ARCH=powerpc on a powerpc host
using gcc 4.2.1 without an explicit XCC assignment that also directs it to gcc
4.2.1 via a full path).
/usr/src/Makefile.inc1 has the following sort of logic:
> .if ${XCC:N${CCACHE_BIN}:M/*}
. . .
> .if defined(X_COMPILER_TYPE) && ${X_COMPILER_TYPE} == gcc
> XCFLAGS+= -isystem ${WORLDTMP}/usr/include -L${WORLDTMP}/usr/lib
> XCXXFLAGS+= -I${WORLDTMP}/usr/include/c++/v1 -std=gnu++11
> -L${WORLDTMP}/../lib/libc++
. . .
> .else
. . .
> .endif
> XCFLAGS+= --sysroot=${WORLDTMP} ${BFLAGS}
> XCXXFLAGS+= --sysroot=${WORLDTMP} ${BFLAGS}
> .else
> .if defined(CROSS_BINUTILS_PREFIX) && exists(${CROSS_BINUTILS_PREFIX})
> BFLAGS+=-B${CROSS_BINUTILS_PREFIX}
> XCFLAGS+= ${BFLAGS}
> XCXXFLAGS+= ${BFLAGS}
> .endif
> .endif # ${XCC:M/*}
For contexts without the -isystem and/or --sysroot in XCFLAGS . . .
Is it appropriate to submit bug reports for buildworld getting include files
from /usr/include instead of from ${WORLDTMP} or from /usr/src areas?
This tends to be noticed when something like the following. . .
> # svnlite update -r295453 /usr/src
> # env __MAKE_CONF=/root/src.configs/make.conf
> SRC_ENV_CONF=/root/src.configs/src.conf.powerpc-gcc421.powerpc-host
> MAKEOBJDIRPREFIX=/usr/obj/gcc421/powerpc.powerpc make -j 6 buildworld
> buildkernel
ends up with compile errors from using some older /usr/include header files
that are no longer sufficient to allow compilation.
I recently had a couple of examples where the cc command in the script output
file for the failing compiles showed no -I , no -isystem , no --sysroot ,
nothing that would have allowed it to even potentially avoid /usr/include (old
file) use. The Makefile*'s involved had no
CFLAGS+=SOMETHING_DIRECTING_INCLUDE_SEARCH .
(Some types of header changes might not stop a build but might make the build
result wrong without much explicit notification. I'd prefer to avoid such as
well.)
I expect that there are analogous points/questions for finding libraries.
===
Mark Millard
markmi at dsl-only.net
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
