On 3/31/16 2:23 PM, Mark Millard wrote:
> Should there be xtoolchain usage notes about avoiding /usr/local/include name
> conflicts and/or about how to assign CC/CXX/XCC/XCXX?
>
> As long as I use gcc49 tools for CC and CXX I still must do things like
> renaming files in /usr/local/include to av
The src.conf that I listed in the original message included the line:
> X_COMPILER_TYPE=gcc
So I'd already done that. Other suggestions?
===
Mark Millard
markmi at dsl-only.net
On 2016-Mar-31, at 2:26 PM, Bryan Drewery wrote:
On 3/31/16 2:23 PM, Mark Millard wrote:
> Should there be xtoolcha
Recent changes have been trying to make things like
powerpc64-xtoolchain-gcc/powerpc64-gcc work better for buildworld/buildkernel.
I happen to do this on a powerpc64 context so the "cross build" is actually
self-hosted. No gcc 4.2.1 is present and clang 3.8.0 and before have code
generation pro
On 3/31/16 2:23 PM, Mark Millard wrote:
> I use the likes of:
>
>> > # diff -rq /usr/include /usr/local/include | grep "^Files "
> to find what to rename for the duration of the system builds.
>
> An example of what happens without the renames is below but I first note the
> use of the name dwar
> On 2016-Mar-31, at 2:32 PM, Bryan Drewery wrote:
>
> On 3/31/16 2:23 PM, Mark Millard wrote:
>> I use the likes of:
>>
# diff -rq /usr/include /usr/local/include | grep "^Files "
>> to find what to rename for the duration of the system builds.
>>
>> An example of what happens without th
On 3/31/16 3:02 PM, Mark Millard wrote:
>> > We likely just need to prioritize /usr/include over /usr/local/include
>> > for these phases, which gcc49 may have backwards since it has its prefix
>> > set to /usr/local from the ports build.
Yup this is the problem with using the ports compiler as th
> On Mar 31, 2016, at 4:34 PM, Bryan Drewery wrote:
> I didn't realize the ports compiler was defaulting /usr/local/include
> into the search path now. It does not have /usr/local/lib in the
> default library path as far as I can tell. It's also broken for its
> -rpath (noted in its pkg-message
On 2016-Mar-31, at 3:34 PM, Bryan Drewery wrote:
> #include "..." search starts here:
> #include <...> search starts here:
> /usr/local/lib/gcc49/include/c++/
> /usr/local/lib/gcc49/include/c++//x86_64-portbld-freebsd11.0
> /usr/local/lib/gcc49/include/c++//backward
> /usr/local/lib/gcc49/gcc/x86_
On 3/31/16 4:42 PM, Mark Millard wrote:
> On 2016-Mar-31, at 3:34 PM, Bryan Drewery wrote:
>> > #include "..." search starts here:
>> > #include <...> search starts here:
>> > /usr/local/lib/gcc49/include/c++/
>> > /usr/local/lib/gcc49/include/c++//x86_64-portbld-freebsd11.0
>> > /usr/local/lib/gc
On 2016-Mar-31, at 5:02 PM, Bryan Drewery wrote:
> This should be fine with my fix too.
>
> Trying add this to your make.conf for now:
>
> CFLAGS.gcc+= -isystem /usr/include
I'll try that. But just FYI: here are the lists of files from gcc49 that having
/usr/include first will change what gcc
On 2016-Mar-31, at 5:02 PM, Bryan Drewery wrote:
> This should be fine with my fix too.
>
> Trying add this to your make.conf for now:
>
> CFLAGS.gcc+= -isystem /usr/include
[Context note: I normally use:
> WITHOUT_CROSS_COMPILER=
> #
> WITH_FAST_DEPEND=
> WITH_LIBCPLUSPLUS=
> WITH_BOOT=
> WI
On 2016-Mar-31, at 8:14 PM, Mark Millard wrote:
>
> On 2016-Mar-31, at 5:02 PM, Bryan Drewery wrote:
>
>> This should be fine with my fix too.
>>
>> Trying add this to your make.conf for now:
>>
>> CFLAGS.gcc+= -isystem /usr/include
>
> [Context note: I normally use:
>
>> WITHOUT_CROSS_COMP
12 matches
Mail list logo
