[Bug 223551] for external toolchain support, X prefix is not setting build utils for make buildworld

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223551

s...@bsdmail.com changed:

   What|Removed |Added

 Status|New |Closed
 Resolution|--- |Works As Intended

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 223551] for external toolchain support, X prefix is not setting build utils for make buildworld

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223551

--- Comment #11 from s...@bsdmail.com ---
(In reply to Mark Millard from comment #10)
It compiles with the X prefix left out of the compiler and utils. I believe it
will complete successfully.

This bug report can be closed. As for the X compiler/utils prefix, it seems
like it is made specifically for if one compiler is used on the host computer,
while another compiler is used for another purpose, cross compiling, and not
needed if there is a sole (ports/pkg) compiler. Thank you.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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"

[Bug 223551] for external toolchain support, X prefix is not setting build utils for make buildworld

[bugzilla-noreply]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223551

--- Comment #10 from Mark Millard  ---
(In reply to sid from comment #9)

What happens if you comment out as below:

 CC= /usr/local/llvm40/bin/clang
 #XCC=/usr/local/llvm40/bin/clang
 CXX=/usr/local/llvm40/bin/clang++
 #XCXX=   /usr/local/llvm40/bin/clang++
 CPP=/usr/local/llvm40/bin/clang-cpp
 #XCPP=   /usr/local/llvm40/bin/clang-cpp

I expect that it would have the same behavior:
absent explicit X?? assignments the ?? assignments
are copied into the internal X??'s before those
X??'s are used.

The same sort of point should apply to AR vs. XAR
and the like if they are similarly duplicates
by content.

You should only needed X?? when you assign
a distinct value from the matching ?? .

That can cut down on the amount of text required
if you care (presuming the test goes as I expect).


I do not see any information for me to analyze for
the rebuild-kernel-twice issue.

But that goes outside this Bugzilla report. I
think we are nearing your being able to close
this report as "not a bug", other than possibly
the original wording in:

https://wiki.freebsd.org/ExternalToolchain

being made clearer.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
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: -r325627 of head: mergemaster: Creating objdir after objdir after . . .

[Bryan Drewery]

On 11/10/2017 8:30 AM, Bryan Drewery wrote:
> On 11/10/17 7:52 AM, Bryan Drewery wrote:
>> On 11/10/2017 12:46 AM, Mark Millard wrote:
>>> When I use the command:
>>>
>>> ~/sys_build_scripts.aarch64-host/mergemaster_cortexA53-aarch64-host.sh 
>>> -FUPi -D/mnt
>>>
>>> based on:
>>>
>>> # more 
>>> ~/sys_build_scripts.aarch64-host/mergemaster_cortexA53-aarch64-host.sh
>>> kldload -n filemon && \
>>> script 
>>> ~/sys_typescripts/typescript_mergemaster_cortexA53_clang_bootstrap_clang-aarch64-host-$(date
>>>  +%Y-%m-%d:%H:%M:%S) \
>>> env __MAKE_CONF="/root/src.configs/make.conf" SRCCONF="/dev/null" 
>>> SRC_ENV_CONF="/root/src.configs/src.conf.cortexA53-clang-bootstrap.aarch64-host"
>>>  \
>>> mergemaster -A aarch64 $*
>>>
>>> in a context where /usr/obj/usr does not exist
>>> (no local build tree present at the time), I get:
>>>
>>> Script started, output file is 
>>> /root/sys_typescripts/typescript_mergemaster_cortexA53_clang_bootstrap_clang-aarch64-host-2017-11-09:23:57:04
>>>
>>> *** Creating the temporary root environment in /var/tmp/temproot
>>>  *** /var/tmp/temproot ready for use
>>>  *** Creating and populating directory structure in /var/tmp/temproot
>>>
>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/share/termcap...]
>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/etc/syslog.d...]
>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/usr.sbin/rmt...]
>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/etc/pam.d...]
>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib...]
>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/csu...]
>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/csu/aarch64...]
>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libc...]
>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libc_nonshared...]
>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libcompiler_rt...]
>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libclang_rt...]
>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libc++...]
>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libc++experimental...]
>>> [Creating nested objdir 
>>> /usr/obj/usr/src/arm64.aarch64/lib/libc++experimental/filesystem...]
>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libcxxrt...]
>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libelf...]
>>> [Creating nested objdir /usr/obj/usr/src/arm64.aarch64/lib/libelf/sys...]
>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/msun...]
>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libalias...]
>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/lib/libalias/libalias...]
>>> . . . (long list) . . .
>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/usr.sbin/wpa/hostapd...]
>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/usr.sbin/wpa/hostapd_cli...]
>>> [Creating objdir /usr/obj/usr/src/arm64.aarch64/usr.sbin/wpa/ndis_events...]
>>>
>>>
>>>
>>> So a /usr/obj/usr/src/arm64.aarch64/ directory tree
>>> ends up being created.
>>
>> Hah, not what we want. I'll fix that.
>>
> 
> In fact it's similar to my META_MODE whitelist in the top-level
> Makefile.  There's quite a few targets we don't care for AUTO_OBJ on,
> like distribute*, installworld, installkernel, etc.

r325697 should fix it.

> 
>> However from reading mergemaster.sh it seems that _at least_
>> /usr/obj/usr/src/etc/sendmail would be created before my changes.  Can
>> someone confirm that on stable/ or something?
>>
>>>
>>> (MAKEOBJDIRPREFIX= does control the path-prefix used
>>> if specified in the env list before mergemaster.)
>>>
>>> ===
>>> Mark Millard
>>> markmi at dsl-only.net
>>>
>>
>>
> 
> 


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: native-xtools gcc archs broken

[Bryan Drewery]

On 11/7/2017 10:18 AM, Bryan Drewery wrote:
> My recent native-xtools rewrite works fine for clang archs but not GCC
> archs.  I am working on a fix.
> 

Fixed in r325673.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature