s
> in the tmpfs earn the end of the builder's activity.
> (This is a amd64 context with 128 GiBytes of RAM and
> 192 GiBytes of swapping/paging space.)
>
> ===
> Mark Millard
> marklmi at yahoo.com
> ( dsl-only.net went
> away in early 2018-Mar)
>
--
Regards,
Bryan Drewery
OpenPGP_signature
Description: OpenPGP digital signature
amd64/stand/efi/boot1
> TARGET boot1.sym.full
> -- command output --
>
> -- filemon acquired metadata --
> . . .
>
>
>
> This bad install hosed the build environment and I'm going to
> build from a different context and then install from there.
> We will see if the other -r347549 context has the same sort
> of problem.
>
> ===
> Mark Millard
> marklmi at yahoo.com
> ( dsl-only.net went
> away in early 2018-Mar)
>
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
On 7/16/2018 3:49 PM, Mark Millard wrote:
>
>
> On 2018-Jul-16, at 3:31 PM, Bryan Drewery wrote:
>
>> On 7/16/18 1:21 PM, Mark Millard wrote:
>>> I attempted a from-scratch (. . ./arm64.aarch64/ empty) kernel-toolchain
>>> buildkernel
>>> target
NG_BOOTSTRAP=
> WITH_CLANG=
> WITH_CLANG_IS_CC=
> WITH_CLANG_FULL=
> WITH_CLANG_EXTRAS=
> WITH_LLD=
> WITH_LLD_IS_LD=
> WITH_LLDB=
> #
> WITH_BOOT=
> WITHOUT_LIB32=
> #
> WITHOUT_GCC_BOOTSTRAP=
> WITHOUT_GCC=
> WITHOUT_GCC_IS_CC=
> WITHOUT_GNUCXX=
> #
> NO_WERROR=
> #WERROR=
> MALLOC_PRODUCTION=
> #
> WITH_REPRODUCIBLE_BUILD=
> WITH_DEBUG_FILES=
> #
> #CROSS_BINUTILS_PREFIX=/usr/local/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}/bin/
> XCFLAGS+= -mcpu=cortex-a53
> XCXXFLAGS+= -mcpu=cortex-a53
> # There is no XCPPFLAGS but XCPP gets XCFLAGS content.
> ACFLAGS.arm64cpuid.S+= -mcpu=cortex-a53+crypto
> ACFLAGS.aesv8-armx.S+= -mcpu=cortex-a53+crypto
> ACFLAGS.ghashv8-armx.S+=-mcpu=cortex-a53+crypto
>
>
> # more ~/src.configs/make.conf
> CFLAGS.gcc+= -v
>
>
>
> ===
> Mark Millard
> marklmi at yahoo.com
> ( dsl-only.net went
> away in early 2018-Mar)
>
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
> On Jun 29, 2018, at 23:32, Mark Millard wrote:
>
>
>
>> On 2018-Jun-29, at 10:45 PM, Mark Millard wrote:
>>
>> Going from -r335799 to -r335812 buildworld buildkernel reported:
>>
>> --- buildworld ---
>> make[1]: "/usr/src/Makefile.inc1" line 342: SYSTEM_COMPILER: Determined that
>> CC=
On 6/27/2018 11:58 AM, Bryan Drewery wrote:
> On 6/27/2018 11:44 AM, Bryan Drewery wrote:
>> On 6/27/2018 10:53 AM, Mark Millard wrote:
>>>
>>>> On 2018-Jun-27, at 10:01 AM, Bryan Drewery wrote:
>>>>
>>>> As of r335704:
>>>>
>&
On 6/27/2018 11:44 AM, Bryan Drewery wrote:
> On 6/27/2018 10:53 AM, Mark Millard wrote:
>>
>>> On 2018-Jun-27, at 10:01 AM, Bryan Drewery wrote:
>>>
>>> As of r335704:
>>>
>>> - make tinderbox/universe will now build the bootstrap clang
On 6/27/2018 10:53 AM, Mark Millard wrote:
>
>> On 2018-Jun-27, at 10:01 AM, Bryan Drewery wrote:
>>
>> As of r335704:
>>
>> - make tinderbox/universe will now build the bootstrap clang *once*.
>> Each target clang is still build of course. This suppo
next few weeks.
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
On 6/20/2018 2:08 PM, Bryan Drewery wrote:
> https://people.freebsd.org/~bdrewery/patches/universe-one-clang.diff
>
> This will build clang once if any of the targets specified (or
> defaulted) require bootstrapping clang.
>
The longterm plan does include making 'TARGET=a
ot sure if that has been committed yet.
Also FYI WITH_SYSTEM_LINKER support is now in to avoid building libclang
for lld on archs that have LLD_BOOTSTRAP set.
I'm putting this out for testing since tinderbox/universe take so long
and I can't possibly test all workflows with it myself.
On 6/18/2018 3:27 PM, Li-Wen Hsu wrote:
> On Mon, Jun 18, 2018 at 5:04 PM Mark Millard via freebsd-toolchain
> wrote:
>>
>> On 2018-Jun-18, at 12:42 PM, Bryan Drewery wrote:
>>
>>> On 6/15/2018 10:55 PM, Mark Millard wrote:
>>>> In watching ci.freeb
On 6/18/2018 3:27 PM, Li-Wen Hsu wrote:
> ranlib -D libpcap.a
> ranlib: fatal: Failed to open 'libpcap.a'
Where is this error even coming from? It's not in the usr.bin/ar code
and ranlib does not cause it.
# ranlib -D uh
ranlib: warning: uh: no such file
--
R
On 6/18/2018 3:31 PM, Li-Wen Hsu wrote:
> On Mon, Jun 18, 2018 at 6:27 PM Bryan Drewery wrote:
>>
>> On 6/18/2018 1:45 PM, Konstantin Belousov wrote:
>>> On Mon, Jun 18, 2018 at 12:42:46PM -0700, Bryan Drewery wrote:
>>>> On 6/15/2018 10:55 PM, Mark Millard wro
On 6/18/2018 1:45 PM, Konstantin Belousov wrote:
> On Mon, Jun 18, 2018 at 12:42:46PM -0700, Bryan Drewery wrote:
>> On 6/15/2018 10:55 PM, Mark Millard wrote:
>>> In watching ci.freebsd.org builds I've seen a notable
>>> number of one time failures, suc
xx-i386.a
> ranlib: fatal: Failed to open 'libclang_rt.asan_cxx-i386.a'
> *** [libclang_rt.asan_cxx-i386.a] Error code 70
>
>
> (Notice the variability in what .a the ranlib's fail for.)
>
>
>
>
>
I looked at this a few days ago and don't believe it's actually a build
race. I think there is something wrong with the ar/ranlib on that system
or something else. I've found no evidence of concurrent building of the
.a files in question.
--
Regards,
Bryan Drewery
___
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"
On 5/19/2018 6:04 PM, Mark Millard wrote:
> On 2018-May-14, at 5:04 PM, Bryan Drewery wrote:
>
>> On 5/13/2018 1:13 AM, Mark Millard wrote:
>>> Retrying the amd64 -> powerpc64 cross build via a powerpc64-gcc
>>> this time, combined with WITH_LIB32= , got: "
On 5/19/2018 6:04 PM, Mark Millard wrote:
> On 2018-May-14, at 5:04 PM, Bryan Drewery wrote:
>
>> On 5/13/2018 1:13 AM, Mark Millard wrote:
>>> Retrying the amd64 -> powerpc64 cross build via a powerpc64-gcc
>>> this time, combined with WITH_LIB32= , got: "
> On 2017-Nov-25, at 4:54 PM, Mark Millard wrote:
>
> . . .
>
> On 2017-Jul-26, at 3:06 AM, Mark Millard wrote:
>
> . . .
>
> ===
> Mark Millard
> marklmi26-fbsd at yahoo.com
> ( dsl-only.net went
> away in early 2018-Mar)
>
>
>
>
>
>
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
On 4/21/18 5:58 PM, Mark Millard wrote:
> /usr/obj/armv7_clang/arm.armv7/usr/src/arm.armv7/tmp/usr/bin/ld: cannot find
> -lgcc_s
This is just an annoying build race due to tools/install.sh not
respecting -S, as far as I remember.
--
Regards,
Bryan Drewery
signature.asc
Description: O
things. DIRDEPS_BUILD replaces the entire build. None of the normal
targets exist, run 'make show-valid-targets' as it says. Really I
suggest not using this mode, it is not really stable and has no
installworld-like mechanism.
--
Regards,
Bryan Drewery
bdrewery@freenode/EFNet
__
ages using 23 builders
> [00:00:12] Starting/Cloning builders
> [00:02:11] Hit CTRL+t at any time to see build progress and stats
>
> It appears that a few second sleep is of significant
> help for having lots of builders.
>
Interesting. I wonder why exactly...
> ===
> Mark Millard
> markmi at dsl-only.net
>
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
below.]
This and the -S issue should both be fixed in
poudriere-devel-3.2.99.20171204_1
I will release it to 3.2.3 later today. Please let me know if it works
for you.
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
[ "${JAILMNT}" = "/" ] && \
> err 1 "Cannot use / for -M"
> fi
> . . .
> SRC_BASE="${JAILMNT}/usr/src"
>
> case ${METHOD} in
> . . .
> null)
> JAILFS=none
> FCT=
> ;;
> esac
>
> if [ "${JAILFS}" != "none" ]; then
> [ -d "${JAILMNT}" ] && \
> err 1 "Directory ${JAILMNT} already exists"
> fi
>
> createfs ${JAILNAME} ${JAILMNT} ${JAILFS:-none}
> . . .
>
>
>
> ===
> Mark Millard
> markmi at dsl-only.net
>
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
On 11/16/2017 1:15 PM, Mark Millard wrote:
>
> ===
> Mark Millard
> mar...@dsl-only.net
>
> On 2017-Nov-16, at 9:13 AM, Bryan Drewery wrote:
>
>>> . . .
>>
>> Can you test this patch please in context of this problem please?
>> It resolves read-
On 11/11/2017 2:25 PM, Mark Millard wrote:
>
> On 2017-Nov-11, at 8:47 AM, Bryan Drewery wrote:
>
>>> On Nov 11, 2017, at 00:51, Mark Millard wrote:
>>>
>>>> On 2017-Nov-10, at 5:16 PM, Bryan Drewery wrote:
>>>>
>>>>> On 11/10/
> On Nov 11, 2017, at 00:51, Mark Millard wrote:
>
>> On 2017-Nov-10, at 5:16 PM, Bryan Drewery wrote:
>>
>>> 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:4
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
>>>
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
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 ~/s
ot what we want. I'll fix that.
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
My recent native-xtools rewrite works fine for clang archs but not GCC
archs. I am working on a fix.
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
concerns have validity. I do think it's time we have an
automated suite to test most build cases for things like bmake upgrades
or other high risk changes like META_MODE.
I'll think about this and add to my list of things to implement.
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
On 11/3/2017 12:42 PM, Mark Millard wrote:
> On 2017-Nov-3, at 11:31 AM, Bryan Drewery wrote:
>
>> On 11/3/17 1:52 AM, Mark Millard wrote:
>>> I did get another problem after buildworld, buildkernel, installkernel
>>> without future source code dates: the in
> M 325351 /usr/src/lib/libkvm/kvm_private.c
>>>> M 325351 /usr/src/sys/arm/allwinner/aw_usbphy.c
>>>> M 325351 /usr/src/sys/arm64/arm64/identcpu.c
>>>> M 325351 /usr/src/sys/boot/fdt/dts/arm/a83t.dtsi
>>&g
-
> ===> lib/librtld_db (all)
> Building
> /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64/lib/librtld_db/rtld_db.o
> --- kerberos5/lib__L ---
> Building
> /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/obj-lib32/amd64.amd64/kerberos5/li
On 11/2/2017 7:46 PM, Warner Losh wrote:
>
>
> On Thu, Nov 2, 2017 at 8:41 PM, Bryan Drewery <mailto:bdrew...@freebsd.org>> wrote:
>
>
>
> > On Nov 2, 2017, at 19:23, Steve Kargl <mailto:s...@troutmask.apl.washington.edu>> wrote:
>
> On Nov 2, 2017, at 19:36, Glen Barber wrote:
>
>> On Thu, Nov 02, 2017 at 07:23:27PM -0700, Steve Kargl wrote:
>> On Thu, Nov 02, 2017 at 07:08:50PM -0700, Bryan Drewery wrote:
>>>> On Nov 2, 2017, at 18:49, Steve Kargl
>>>> wrote:
>>>>
> On Nov 2, 2017, at 19:23, Steve Kargl
> wrote:
>
>> On Thu, Nov 02, 2017 at 07:08:50PM -0700, Bryan Drewery wrote:
>>
>>
>>>> On Nov 2, 2017, at 18:49, Steve Kargl
>>>> wrote:
>>>>
>>>> On Thu, Nov 02, 2017 at
> On Nov 2, 2017, at 18:49, Steve Kargl
> wrote:
>
>> On Thu, Nov 02, 2017 at 06:25:24PM -0700, Bryan Drewery wrote:
>>
>> On Nov 2, 2017, at 15:44, Mark Millard wrote:
>>
>>>> Author: bdrewery
>>>> Date: Thu Nov 2 22:2
On Nov 2, 2017, at 15:44, Mark Millard wrote:
>> Author: bdrewery
>> Date: Thu Nov 2 22:23:00 2017
>> New Revision: 325347
>> URL:
>> https://svnweb.freebsd.org/changeset/base/325347
>>
>>
>> Log:
>> Something is very wrong
Unfortunately I only test with META_MODE these days which implies
obj-cross-tools vs.
> obj-bootstrap-tools :
>
> /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-cross-tools/lib/clang/libllvmminimal/libllvmminimal.a
> /usr/obj/bpim3_clang/arm.armv7/usr/src/arm.armv7/tmp/obj-bootstrap-tools/lib/clang/libllvmminimal/libllvmminimal.a
>
>
> ===
> Mark Millard
> markmi at dsl-only.net
>
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
1.0.3: Success
> [00:20:29] [01] [00:15:41] Finished devel/binutils | binutils-2.28,1: Success
> [00:20:30] [01] [00:00:00] Building lang/gcc7 | gcc7-7.2.0
>
> So I expect that the change is appropriate.
>
>
> [Unfortunately qemu-ppc64-static seems to not work:
> the qemu-ppc64
better
about using the provided /usr/src or erroring if none if found or if the
format is not correct.
Thanks, will fix it all.
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
; workaround.]
Thanks for the information. I haven't been able to reproduce it in the
past; I'll review your build and see if I can figure it out.
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
On 7/24/2017 11:20 AM, Bryan Drewery wrote:
> On 7/22/2017 9:04 PM, Mark Millard wrote:
>> After buildworld buildkernel installkernel installkernel reboot to
>> upgrade to -r321371 (from -r321109 ) I attempted:
>>
>> ~/sys_build_scripts.amd64-host/make_amd64_
rti
> 1 error
>
>
> Removing the -j8 got past this (but got a later problem that
> I'll report separately).
I am not surprised, there is no .ORDER defined for running installworld
distrib-dirs and distribute all at the same time with -j. I can make it
parallel-safe though.
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
difference in meta mode incremental build results
> vs. full rebuild.
This was a bug with buildkernel with META_MODE using filemon (the
default with META_MODE). It is fixed in r320919. I recommend doing
another buildkernel after that and installing to ensure everything gets
updated.
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
On 7/5/17 1:35 PM, Mark Millard wrote:
> On 2017-Jul-5, at 12:36 PM, Bryan Drewery wrote:
>
>> On 6/29/17 6:21 PM, Mark Millard wrote:
>>> [I found where the tools are listed that are copied,
>>> the list that is missing head.]
>>>
>>> . . .
>&
;> GNU ld (GNU Binutils) 2.28
>>
>> So /tmp/install.7ljKosWa/ just needed a copy of head
>> in addition to what it already had.
>
> In /usr/src/Makefile.inc1 :
>
> ITOOLS= [ awk cap_mkdb cat chflags chmod chown cmp cp \
> date echo egrep find grep id install ${_install-info} \
> ln make mkdir mtree mv pwd_mkdb \
> rm sed services_mkdb sh strip sysctl test true uname wc ${_zoneinfo} \
> ${LOCAL_ITOOLS}
>
> does not list "head" as a tool.
>
> But I can externally add it via LOCAL_ITOOLS use.
>
This change should not be needed. We don't want to be running 'ld'
during installworld. The changes I made around this time should already
cover the problem. Is it still occurring on a more recent
buildworld+installworld, without the ITOOLS change?
>
> ===
> Mark Millard
> markmi at dsl-only.net
>
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
x27;
> . . .
>
> and its later consequences.
>
> Since it is already a failed build I just ^C out.
>
r319996 should fix it. Thanks for letting me know!
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
It's a meta mode only thing. I'll look at it shortly.
Regards,
Bryan Drewery
> On Jun 15, 2017, at 20:05, Mark Millard wrote:
>
> I've been having amd64 -> powerpc cross builds that
> stop with sed waiting for terminal input:
>
> 780 0 Is 0:00.00 -
mon && \
> script
> ~/sys_typescripts/typescript_make_powerpcvtsc_nodebug_gcc421_bootstrap_clang-amd64-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.powerpc-gcc421-bootstrap-clang.amd64-host"
> \
> WITH_META_MODE=yes \
Thanks for the report. Fixed in r318092.
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
later. Just stick to src.conf unless
you need to set one of the options that requires src-env.conf.
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
p.o: In function `atfu_mktemp_not_exist_body':
>>> >> /usr/src/contrib/netbsd-tests/lib/libc/stdio/t_mktemp.c:47: warning:
>>> >> warnin=
>>> >> g: mktemp() possibly used unsafely; consider using mkstemp()
>>> >> /usr/obj/i386.i386/usr
feature was that when we bumped the
compiler revision, too much of clang would rebuild. That was addressed
in r301277.
I would like to enable this feature by default in head for 11.0.
Unless there are any objections I will do so in a few days.
--
Regards,
Bryan Drewery
signature.asc
Description
_iterate_object'
> uclparse.o: In function `uclparse_auth_group':
> /usr/src/usr.sbin/ctld/uclparse.c:396: undefined reference to
> `ucl_iterate_object'
> /usr/src/usr.sbin/ctld/uclparse.c:416: undefined reference to
> `ucl_iterate_object'
> uclparse.o:/usr/src/usr.sbin/ctld/uclparse.c:431: more undefined references
> to `ucl_iterate_object' follow
> uclparse.o: In function `uclparse_target_lun':
> /usr/src/usr.sbin/ctld/uclparse.c:202: undefined reference to
> `ucl_object_find_key'
> /usr/src/usr.sbin/ctld/uclparse.c:203: undefined reference to
> `ucl_object_find_key'
> uclparse.o: In function `uclparse_target':
> /usr/src/usr.sbin/ctld/uclparse.c:731: undefined reference to
> `ucl_iterate_object'
> collect2: error: ld returned 1 exit status
>
> *** [ctld.full] Error code 1
>
> make[4]: stopped in /usr/src/usr.sbin/ctld
> 1 error
>
> make[4]: stopped in /usr/src/usr.sbin/ctld
> *** [all_subdir_usr.sbin/ctld] Error code 2
>
>
>
>
> ===
> Mark Millard
> markmi at dsl-only.net
>
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
toolchains on OSes (eg macosx)
> where it may already generate freebsd binaries and as such we should
> be calling the compiler/linker with all the flags it needs.
>
> Having a patched compiler default for mips made things way, way harder
> than it needed to be.
>
>
--
Re
> #include <...> search starts here:
>
> /root/svn/ports/lang/gcc49/work/stage/usr/local/bin/../lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include
>
> /root/svn/ports/lang/gcc49/work/stage/usr/local/bin/../lib/gcc49/gcc/x86_64-portbld-freebsd11.0/4.9.4/include-fixed
&g
include path hacks
progresses the build further.
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
On 5/23/16 2:41 PM, Mark Millard wrote:
> Relative to (Bryan Drewery Mon May 23 16:40:23 UTC 2016):
>
>> A critical note to toolchain developers, or anyone who touches the Clang
>> or GCC source files. If you modify these files or add a new target
>> architecture int
not pass.
--
Regards,
Bryan Drewery
___
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"
bsd/Makefile.inc1" line 144:
> SMART_CROSS_COMPILER: Determined that CC=/usr/local/bin/ccache cc matches the
> source tree. Not bootstrapping a cross-compiler.
A future improvement will be to build 1 clang before universe if
/usr/bin/cc cannot be used. It will not be a cross-compile
_fn_sh_complete)
>
> The details. . .
FYI this was fixed in r297435.
--
Regards,
Bryan Drewery
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "
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/incl
clude
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). So having a default
/usr/local/include path seems odd.
Adding -isystem /usr/include to fix this is probably possible b
msg'
>> > dwarf.o:/usr/src/cddl/usr.bin/ctfconvert/../../../cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c:418:
>> > more undefined references to `dwarf_errmsg' follow
>> > dwarf.o: In function `dw_read':
>> > /usr/src/cddl/usr.bin/ctfco
ocal/include to avoid them interfering with system
> headers:
Try setting X_COMPILER_TYPE=gcc as well.
--
Regards,
Bryan Drewery
___
freebsd-toolchain@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe
On 3/24/2016 3:39 PM, Warner Losh wrote:
>
>> On Mar 24, 2016, at 4:36 PM, Bryan Drewery wrote:
>>
>> Is there any problem with forcing -std=c++11 for all CXX/LIB_CXX builds
>> now? We do this when using an external GCC since it doesn't default to
>> the
On 3/24/2016 4:16 PM, Dimitry Andric wrote:
> On 24 Mar 2016, at 23:54, Dimitry Andric wrote:
>>
>> On 24 Mar 2016, at 23:51, Bryan Drewery wrote:
> ...
>>> It fails without -std=c++11 (there's more discussion in that link and in
>>> PR 205453).
>>
On 3/24/2016 4:13 PM, Bryan Drewery wrote:
> Well _Static_assert is C++11 and static_assert is C11.
Yes I have it backwards, same point though.
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
On 3/24/2016 3:54 PM, Dimitry Andric wrote:
> On 24 Mar 2016, at 23:51, Bryan Drewery wrote:
>>
>> On 3/24/2016 3:45 PM, Bryan Drewery wrote:
>>> On 3/24/2016 3:44 PM, Dimitry Andric wrote:
>>>> On 24 Mar 2016, at 23:36, Bryan Drewery wrote:
>>>>
On 3/24/2016 3:45 PM, Bryan Drewery wrote:
> On 3/24/2016 3:44 PM, Dimitry Andric wrote:
>> On 24 Mar 2016, at 23:36, Bryan Drewery wrote:
>>>
>>> Is there any problem with forcing -std=c++11 for all CXX/LIB_CXX builds
>>> now? We do this when using an exte
On 3/24/2016 3:44 PM, Dimitry Andric wrote:
> On 24 Mar 2016, at 23:36, Bryan Drewery wrote:
>>
>> Is there any problem with forcing -std=c++11 for all CXX/LIB_CXX builds
>> now? We do this when using an external GCC since it doesn't default to
>> the c++11
On 3/24/2016 3:39 PM, Warner Losh wrote:
>
>> On Mar 24, 2016, at 4:36 PM, Bryan Drewery wrote:
>>
>> Is there any problem with forcing -std=c++11 for all CXX/LIB_CXX builds
>> now? We do this when using an external GCC since it doesn't default to
>> the
d.org/pipermail/freebsd-toolchain/2015-October/001757.html
which I've fixed in an upcoming commit to properly pass -std=c++11 to
the lib32 build in CXXFLAGS.
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
On 3/11/2016 9:10 AM, Bryan Drewery wrote:
> WITH_FAST_DEPEND is now enabled by default for in-tree and out-of-tree
> builds. It no longer runs mkdep(1) during 'make depend', and the
> 'make depend' stage can safely be skipped now as it is auto ran
> when building
before
building anything else. Dependencies are gathered at compile time with
-MF flags kept in separate .depend files per object file. Users should
run 'make cleandepend' once if using -DNO_CLEAN to clean out older
stale .depend files.
The option and mkdep(1) support will be removed in
On 12/8/15 2:14 PM, Bryan Drewery wrote:
> On 12/7/15 1:33 PM, Mark Millard wrote:
>>
>>> On 2015-Dec-7, at 12:48 PM, Simon J. Gerraty wrote:
>>>
>>> Mark Millard wrote:
>>>> My guess is that it is picking up the
>>>>
>>>&g
On 12/15/15 10:54 AM, Mark Millard wrote:
> On 2015-Dec-15, at 10:37 AM, Bryan Drewery wrote:
>>
>> On 12/8/15 2:14 PM, Bryan Drewery wrote:
>>> On 12/7/15 1:33 PM, Mark Millard wrote:
>>>>
>>>>> On 2015-Dec-7, at 12:48 PM, Simon J. Gerraty wrot
I miss something?
Yes. sys.mk and src-env.conf are included *before* Makefile. Think of it
as being in line 0.
Technically you should be able to use MAKEOBJDIRPREFIX in make.conf or
src.conf if you are not using any of the meta mode features (all off by
default).
--
Regards,
Bryan Drewery
___
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"
On 11/13/2015 1:38 PM, Simon J. Gerraty wrote:
> Bryan Drewery wrote:
>
>> On 11/13/2015 9:22 AM, Simon J. Gerraty wrote:
>>> Bryan Drewery wrote:
>>>>> WITH_META_FILES should give you improvements already in that regard.
>>>>
>>>> Ye
On 11/13/2015 9:22 AM, Simon J. Gerraty wrote:
> Bryan Drewery wrote:
>>> WITH_META_FILES should give you improvements already in that regard.
>>
>> Yes, it's a step. We'll need cookies in a lot of places too. I wish
>> WITH_META_MODE had been WITH_MET
On 11/12/2015 3:42 PM, Simon J. Gerraty wrote:
> Bryan Drewery wrote:
>
>> On 9/3/2015 11:46 AM, Simon J. Gerraty wrote:
>>> Anyway, bootstrap-toolchain leverages src/Makefile.inc1 to build an
>>> initial set of tools. It then attempts to use that to build toolch
it, using WITHOUT_CROSS_COMPILER (or WITHOUT_*_BOOTSTRAP)
with buildworld leads to a broken build currently since it is the user
basically asking to use their default external toolchain of /usr/bin/*,
but the logic does not kick in to use --sysroot against WORLDTMP. I plan
to fix this soon as well.
--
Regards,
Bryan Drewery
signature.asc
Description: OpenPGP digital signature
bdrewery added a subscriber: bdrewery.
bdrewery accepted this revision.
bdrewery added a reviewer: bdrewery.
bdrewery added a comment.
+1
'CC' is easily confused with '${CC}' and is difficult to even discuss. So much
of the development ecosystem tells people to use 'gcc' or 'g++' anyhow,
removi
86 matches
Mail list logo
