ports-mgmt/poudriere-devel, lang/rust (for example), and USE_TMPFS that includes wrkdir (or yes)

ir included in USE_TMPFS shows over 130 GiBytes 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)

Re: devel/llvm10 (and 11) on aarch64: only BE_AMDGPU registered targets despite OPTIONS_FILE_SET+=BE_NATIVE also being set

On 2021-Apr-8, at 10:46, Mark Millard wrote: > Building devel/llvm10 via poudriere-devel on a Cortex-A57 > system (OverDrive 1000), I ended up with just: > > # /usr/local/llvm10/bin/llc -version > LLVM (http://llvm.org/): > LLVM version 10.0.1 > Optimized build. >

devel/llvm10 (and 11) on aarch64: only BE_AMDGPU registered targets despite OPTIONS_FILE_SET+=BE_NATIVE also being set

88ec59866cf2878263e7f3b2 merge-base: CommitDate: 2021-03-12 20:29:42 + 7381bbee29df (freebsd/main, freebsd/HEAD, pure-src, main) cam: Run all XPT_ASYNC ccbs in a dedicated thread n245444 (--first-parent --count for merge-base) === Mark Millard marklmi at

/usr/lib/libomp.so : is there a reason that aarch64 does not have such by default?

| --||--| | Linux* OS | Yes(1,2) | Yes(3,4) | --- . . . ENDQUOTE Nothing stands out for why WITH_OPENMP is in use by default only for amd64, i386, and powerpc64. === Mark Millard marklmi at yahoo.com ( dsl

CPU_FFS, its ffsl use, and the need for including if using "ISO" compiler modes

I'll note that g++10 did not object before this change. But I had reason to also build using g++9 . [Compiling the -updated code with g++10 did not complain. Nor did linking the results complain.] Note: The c++17 code involved is not part of a FreeBSD port. === Mark Millard marklmi at yahoo.co

Re: aarch64: unable to use lang/gcc10 to use system libc++ . . . [ unless I use -mno-outline-atomics for gcc10's 10.1 and later]

On 2020-Aug-4, at 16:52, Mark Millard wrote: > On 2020-Aug-4, at 14:27, Mark Millard wrote: >> >> Historically I've been able to use lang/gcc9 to build personal >> aarch64 c++17 applications that used head's libc++ and the >> like (other than some fl

Re: aarch64: unable to use lang/gcc10 to use system libc++, unlike back with lang/gcc9, failure: __aarch64_ldadd8_acq_rel missing

On 2020-Aug-4, at 14:27, Mark Millard wrote: > > Historically I've been able to use lang/gcc9 to build personal > aarch64 c++17 applications that used head's libc++ and the > like (other than some floating point support code for aarch64). > The redirection of g++9 to

aarch64: unable to use lang/gcc10 to use system libc++, unlike back with lang/gcc9, failure: __aarch64_ldadd8_acq_rel missing

do not do that" land? Or is this something that should be possible but is currently broken? Note: The C++ source in question tries to be pure C++17 compliant code for normal builds. (And I was doing a normal build: no FreeBSD specific code or the like enabled.) === Mark Millard marklmi a

Re: Introduce WITH(OUT)_LTO? (was: Re: svn commit: r362987 - in head: contrib/bc usr.bin/gh-bc) (LLVMgold.so and gnu's ld.gold)

On 2020-Jul-25, at 13:59, Mark Millard wrote: > On 2020-Jul-8, at 01:28, Stefan Eßer wrote: > >> Am 08.07.20 um 09:01 schrieb Mark Millard: >>> The following is more informational than anything as far >>> as I'm concerned. But there may be implications th

Re: Introduce WITH(OUT)_LTO? (was: Re: svn commit: r362987 - in head: contrib/bc usr.bin/gh-bc) (LLVMgold.so and gnu's ld.gold)

On 2020-Jul-8, at 01:28, Stefan Eßer wrote: > Am 08.07.20 um 09:01 schrieb Mark Millard: >> The following is more informational than anything as far >> as I'm concerned. But there may be implications that I'm >> unaware of. (I sometimes experiment with toolchain

Re: svn commit: r363031 - in head: contrib/bmake contrib/bmake/lst.lib contrib/bmake/mk contrib/bmake/mk/sys contrib/bmake/unit-tests usr.bin/bmake (make now broken)

On 2020-Jul-8, at 20:35, Yuri Pankov wrote: > Mark Millard wrote: >> This seems to have broken doing buildworld buildkernel and >> other things using make: >> make[2]: "/usr/src/share/mk/bsd.compiler.mk" line 197: warning: String >> comparison operato

Re: svn commit: r363031 - in head: contrib/bmake contrib/bmake/lst.lib contrib/bmake/mk contrib/bmake/mk/sys contrib/bmake/unit-tests usr.bin/bmake (make now broken)

g", rhs = "gcc", op = == . . . left = 0.00, right = 6.00, op = <= left = 0.00, right = 3.00, op = <= lhs = "clang", rhs = "gcc", op = == make[3]: "/usr/src/share/mk/bsd.sys.mk" line 81: warning: String comparison operator should be

Re: Introduce WITH(OUT)_LTO? (was: Re: svn commit: r362987 - in head: contrib/bc usr.bin/gh-bc)

On 2020-Jul-8, at 01:28, Stefan Eßer wrote: > Am 08.07.20 um 09:01 schrieb Mark Millard: >> The following is more informational than anything as far >> as I'm concerned. But there may be implications that I'm >> unaware of. (I sometimes experiment with toolchain

powerpc (32-bit): error: statement with no effect at sys/net/iflib.c:1258 : #define iflib_netmap_txq_init(ctx, txq) (0)

k /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.linker.mk /usr/src/sys/conf/kern.opts.mk /usr/src/sys/conf/config.mk /usr/src/share/mk/bsd.links.mk /usr/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.mk /usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk /usr/

powerpc64: error: 'tmp' is used uninitialized in 'atomic_cmpset_masked' stops buildkernel via gcc9

; /* failure - retval = 0 */ "3:\n\t" : "=&r" (ret), "=m" (*p), "+&r" (tmp) : "r" (p), "r" (cmpval), "r" (newval), "m" (*p), "r&

Re: svn commit: r362987 - in head: contrib/bc usr.bin/gh-bc

e/mk/bsd. incs.mk /usr/src/share/mk/bsd.links.mk /usr/src/share/mk/bsd.man.mk /usr/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.mk /usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk /usr/src/share/mk/bsd.sys.mk' .PATH='. /usr/src/usr.bin/gh-bc /usr/src/contrib/bc/src

WITHOUT_BINUTILS= based head -r356427 FreeBSD context: x11-toolkits/qt5-gui build fails in poudriere: unable to execute command: Executable "as" doesn't exist!

neon_asm.o . . . --- .obj/qdrawhelper_neon_asm.o --- cc: error: unable to execute command: Executable "as" doesn't exist! This suggests that a dependency on a ports binutils is needed and use of it is needed to keep this building when binutils 2.17.50 is absent in head. === Mark Mil

Re: head -r358966 on aarch64 fails to build base/gcc6: fatal error: bracket nesting level exceeded maximum of 256

On 2020-Mar-23, at 09:48, John Baldwin wrote: > On 3/20/20 11:02 PM, Mark Millard wrote: >> While trying to build base/gcc6 on aarch64 (implicitly targeting aarch64: >> self hosted), it failed with: >> >> . . . >> c++: warning: treating 'c' input

head -r358966 on aarch64 fails to build base/gcc6: fatal error: bracket nesting level exceeded maximum of 256

pc so more ports can build.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail t

head -r358966 attempting system lldb build, targeting powerpc64: still gets undefined symbol: lldb_private::formatters::CMTimeSummaryProvider ...

10 materials has not changed the status. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send

A small llvm/clang patch for powerpc that Roman Divacky provided back in 2017-May: keep or revert?

d)? If it is not relevant to head, then I could revert the patch in my environment. If it is relevant to llvm, I'd probably try to contact Roman to remind him of the patch in case he would want it in llvm. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)

powerpc64 clang 9 ABI vs. gcc ABI and clang V10 and FreeBSD 13: -msvr4-struct-return by default for clang in order to match gcc/g++?

hange before 13 freezes. I originally ran into this using C++'s steady-clock's now return values, leading to program crashes from the mismatched ABI's when I had g++ using the FreeBSD system headers and libraries instead of the gcc ones (so libc++ was in use, for example). === Mar

Re: head -r357401 broke my powerpc/powerpc64 builds: I build with sc present [the added "static" caused the failures]

[Turns out to be the added "static".] On 2020-Feb-2, at 15:10, Mark Millard wrote: > [I forgot to send some context.] > > On 2020-Feb-2, at 14:51, Mark Millard wrote: > >> --- kernel.full --- >> ld: error: undefined symbol: dflt_font_8

Re: head -r357401 broke my powerpc/powerpc64 builds: I build with sc present

[I forgot to send some context.] On 2020-Feb-2, at 14:51, Mark Millard wrote: > --- kernel.full --- > ld: error: undefined symbol: dflt_font_8 >>>> referenced by ofw_syscons.c >>>> ofw_syscons.o:(.toc+0x10) > ld: error: undefined symbol

head -r357401 broke my powerpc/powerpc64 builds: I build with sc present

nd \ clean "font.h ${SC_DFLT_FONT}-8x14 ${SC_DFLT_FONT}-8x16 ${SC_DFLT_FONT}-8x8" in /head/sys/conf/files.powerpc . FYI for why I have sc present: Historically, I've had two PowerMac contexts, one of which worked with sc but not vt an

head -r356426 32-bit powerpc : clang vs gcc9 C-ABI: *not* the same: clang is doing -maix-struct-return style

register r3 and r4. This appears to be -msvr4-struct-return style. So is clang using the aix ABI the right ABI? Or does GCC need to change? === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain

head -r356426 for 32-bit powerpc vs. powerpc-unknown-freebsd13.0-g++9 and g++9: not (fully) clang++-ABI compatible (using system-headers and libraries, not gcc's)

efix=/usr/local --localstatedir=/var --mandir=/usr/local/man --infodir=/usr/local/share/info/ --build=powerpc-unknown-freebsd13.0 Thread model: posix gcc version 9.2.0 (FreeBSD Ports Collection for powerpc) # c++ -v FreeBSD clang version 9.0.1 (g...@github.com:llvm/llvm-project.git c1a0a213378

The 32-bit powerpc FreeBSD early-boot "tfo_ccache_bucket panic" on (2 socket?) G5s: visible at -r356118, not happening at -r356109

tcp_fastopen_init+0x1e8 0xd0004a20: at tcp_init+0x234 0xd0004a50: at protosv_init+0x1d4 0xd0004a60: at vnet_domain_init+0x5c 0xd0004a80: at vnet_register_sysinit+0x154 0xd0004ab0: at mi_startup+0x280 0xd0004af0: at btext+0x74 KDB: enter: panic [ thread pid 0 tid 10 ] Stopped at kdb_enter+0x74: addi r3

Re: svn commit: r356289 - head

is an intent to support a (modern) GNU binutils ld (in addition to lld) or not. So it may be that the effort would not be put in. (I'm not claiming which side(s) would change if the effort was put in.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___

Re: 32-bit powerpc kernel builds (head -r356187): old ld (works) vs. devel/binutils@powerpc based (fails to boot): DYNAMIC vs. EXEC_P (powerpc64 lld too)

On 2019-Dec-31, at 16:44, Mark Millard wrote: > On 2019-Dec-31, at 14:52, Mark Millard wrote: > >> My attempt to buildkernel via devel/binutils@powerpc >> produces a kernel that gets a very early crash. >> >> Looking at the normal and alter

For reliable builds, gnu/usr.bin/binutils/Makefile needs similar to gnu/usr.bin/binutils/Makefile.inc0 TARGET_CPUARCH use, not ${TARGET} use

using ${TARGET} . Many places were using ${MACHINE_CPUARCH} . But straight use of ${MACHINE_CPUARCH} here did not work for the context. Thus, I went for the more general code from Makefile.inc0 instead, reusing what others had already figured out.) === Mark Millard marklmi at yahoo.com (

Re: A devel/freebsd-gcc*/Makefile suggestion to avoid base/binutil preventing freebsd-gcc* builds

On 2019-Dec-31, at 16:37, John Baldwin wrote: > On 12/26/19 7:54 PM, Mark Millard wrote: >> Context: devel/freebsd-gcc* (for example) >> using: >> >>--with-as=${LOCALBASE}/bin/${BU_PREFIX}-as \ >>--with-ld=${LOCALBASE}/bin/${

Re: devel/freebsd-gcc9@powerpc (for example) : it has the clang vs. gcc vec_step name conflict (for powerpc families): build fails under clang

On 2019-Dec-31, at 16:41, John Baldwin wrote: > On 12/26/19 11:39 PM, Mark Millard wrote: >>>> is missing the patch-clang-vec_step that is in: >>>> >>>> FBSDG5L2# ls -laT /usr/ports/lang/gcc9/files/ >>> >>> That is a hack that can b

Re: 32-bit powerpc kernel builds (head -r356187): old ld (works) vs. devel/binutils@powerpc based (fails to boot): DYNAMIC vs. EXEC_P

On 2019-Dec-31, at 14:52, Mark Millard wrote: > My attempt to buildkernel via devel/binutils@powerpc > produces a kernel that gets a very early crash. > > Looking at the normal and alternate kernels a little > shows. . . > > > > Old ld (and such): > > /bo

32-bit powerpc kernel builds (head -r356187): old ld (works) vs. devel/binutils@powerpc based (fails to boot): DYNAMIC vs. EXEC_P

/red/herring -X -o kernel.full locore.o . . . === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe

Re: system-clang (elfv2) and devel/binutil@powerpc (32-bit): booting fail very early on PowerMac3,6 example ; also build problem why I tried this

On 2019-Dec-30, at 18:14, Mark Millard wrote: > Because of the (cross-)build failure (from amd64): > > --- acl_nfs4.ko.full --- > ld: acl_nfs4.kld(.text+0x234): R_PPC_PLTREL24 reloc against local symbol > acl_nfs4.kld: could not read symbols: Bad value > *** [acl_nfs4.ko.

system-clang (elfv2) and devel/binutil@powerpc (32-bit): booting fail very early on PowerMac3,6 example ; also build problem why I tried this

00181c 248 FUNCLOCAL DEFAULT1 acl_nfs4_check === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsub

devel/binutils@powerpc64 ( powerpc64-unknown-freebsd13.0-ld ) unbounded loop in bfd/elf64-ppc.c : the source code and values

/binutils-2.33.1/bfd/elf64-ppc.c The 1st line quoted above was line 7455 according to vi. Ref reference, both of the stuck links (clang.full and lld.full) have: (gdb) print r_type $1 = R_PPC64_REL16_HA (gdb) print/x *rel $3 = {r_offset = 0x2, r_info = 0x1800fc, r_addend = 0x2} === Mar

Building head -r356187 for powerpc64 via devel/freebsd-gcc9 fails: powerpc64-unknown-freebsd13.0-ld: over 480 cpu minutes on ThreadRipper 1950X

combination to complete buildworld buildkernel was system-clang with devel/binutils@powerpc . The default system linker failed with acl_nfs4.kld(.text+0x234): R_PPC_PLTREL24 reloc against local symbol. Using devel/freebsd-gcc9@powerpc with devel/binutils@powerpc resulted in forced bss-plt us

LDFLAGS.lld+= vs. 32-bit powerpc related use of ld.bfd in a powerpc64 overall build (head -r356187)

rc/share/mk/bsd.clang-analyze.mk /usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk /usr/src/share/mk/bsd.sys.mk' .PATH='. /usr/src/stand/powerpc/boot1.chrp /usr/src/sys/libkern /usr/src/lib/libc/powerpc/gen /usr/src/stand/powerpc/boot1.chrp' 1 error === Mark Millard ma

x11-toolkits/qt5-gui build on/for Cortex-A7 ( head -r356109 ) failed with: unable to execute command: Executable "as" doesn't exist

-gnueabihf Thread model: posix InstalledDir: /usr/bin # svnlite info /usr/ports/ Path: /usr/ports Working Copy Root Path: /usr/ports URL: svn://svn.freebsd.org/ports/head Relative URL: ^/head Repository Root: svn://svn.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5

devel/aarch64-none-elf-gcc build failed with long list of "pkg-static: Unable to access file . . ." during package stage

el/aarch64-none-elf-gcc | aarch64-none-elf-gcc-6.4.0_7 ended at Sat Dec 28 04:40:12 PST 2019 FreeBSD head -r356109 based context. ports -r520539 based context. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ fr

base/binutils build on 32-bit powerpc fails for not finding elf64_fbsd.* ldscripts

g4ports drwxr-xr-x 3 root wheel 512 Dec 28 02:07:44 2019 /wrkdirs/usr/ports/print/indexinfo (I already had pkg 1.12.0 added.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org maili

Re: devel/freebsd-gcc9@powerpc (for example) : it has the clang vs. gcc vec_step name conflict (for powerpc families): build fails under clang

On 2019-Dec-26, at 20:49, Gerald Pfeifer wrote: > On Thu, 26 Dec 2019, Mark Millard wrote: >> I tried to build devel/freebsd-gcc9@powerpc on a powerpc64 (in an >> ELFv1 clang environment) and it reported (listing just one of the >> examples that pointed to vec_step): >

A devel/freebsd-gcc*/Makefile suggestion to avoid base/binutil preventing freebsd-gcc* builds

mips mips64 powerpc powerpc64 riscv64 sparc64 TARGETARCH=${FLAVOR} This avoids later not finding the file via the full path in such contexts. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain

Re: devel/freebsd-gcc9@powerpc (for example) : it has the clang vs. gcc vec_step name conflict (for powerpc families): build fails under clang

On 2019-Dec-26, at 15:21, Mark Millard wrote: > I tried to build devel/freebsd-gcc9@powerpc on a powerpc64 (in an > ELFv1 clang environment) and it reported (listing just one of the > examples that pointed to vec_step): > > > /wrkdirs/usr/ports/devel/freebsd-gcc9/work-pow

devel/freebsd-gcc9@powerpc (for example) : it has the clang vs. gcc vec_step name conflict (for powerpc families): build fails under clang

932 Dec 25 19:25:10 2019 patch-powerpc32 -rw-r--r-- 1 root wheel 294 Sep 15 13:10:46 2019 pkg-message.in I do not know if other differences in the patch lists might be important to other aspects (in either direction). === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 201

Re: For devel/freebsd-gcc9@powerpc64 and devel/binutils@powerpc64 use: internal compiler error: in rs6000_pltseq_template, at config/rs6000/rs6000.c:21873

On 2019-Dec-21, at 16:40, Mark Millard wrote: > This was for a amd64->powerpc64 buildworld for a head > -r355976 based context. > > The there is lots of command argument information from > the gcc toolchain being used with -v. The .meta report > also shows such. >

For devel/freebsd-gcc9@powerpc64 and devel/binutils@powerpc64 use: internal compiler error: in rs6000_pltseq_template, at config/rs6000/rs6000.c:21873

ment-macros -Wno-error=restrict -Wno-error=sizeof-pointer-memaccess -Wno-error=stringop-truncation -std=gnu99 -version -o crt1.s GNU C99 (FreeBSD Ports Collection for powerpc64) version 9.2.0 (powerpc64-unknown-freebsd13.0) compiled by GNU C version FreeBSD Clang 9.0.0 (tags/RELEASE_900/f

devel/freebsd-gcc9@aarch64 and devel/binutils@aarch64: locore.S vs. gcc toolchain notational mismatch (icc_sre_el2)

_el2, x2 2: /* Set the address to return to our return address */ msr elr_el2, x30 isb (devel/freebsd-gcc6 likely has the same status.) The context was head -r355976 based. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) __

buildworld for 32-bit powerpc via devel/freebsd-gcc9@powerpc (not clang): still gets the bss-plt being forced due to crtbeginS.o (build stopped)

7; '-Winline' '-Wnested-externs' '-Wredundant-decls' '-Wold-style-definition' '-Wno-pointer-sign' '-Wno-error=address' '-Wno-er ror=array-bounds' '-Wno-error=attributes' '-Wno-error=bool-compare' '-Wno-error=c

Re: New external GCC toolchain ports/packages

r 12.x). > > I do plan to switch the default toolchains for make universe/tinderbox > for targets using -xtoolchain-gcc based on GCC 6 over to the > freebsd-gcc6 variants in the next week or so. > How about base/binutils and b

Re: head -r355761 for amd64 self-hosted: installworld failed for: "btxld: not found" (-r35777 too, more sequencing evidence)

On 2019-Dec-14, at 19:13, Mark Millard wrote: > I give various details based on how I got past it as well > as the original error messages. > > This was a -j32 threadripper 1950X context at the start: > the installworld with -j32 got: > > --- realinstall_subdir_st

head -r355761 for amd64 self-hosted: installworld failed for: "btxld: not found"

-rw-r--r--1 root wheel971 Nov 9 08:29:35 2018 btxld.8.gz.meta -rw-r--r--1 root wheel 1429 Nov 9 08:29:35 2018 btxld.8.gz I do not know if this is some sort of race that silently stopped btxld and btxld.debug from being generated (despite the "Building" lines). === Mark

head src.conf loses almost all references to powerpc in -r353933 (and later)

.0.0/projects/libcxx/docs/ReleaseNotes.html PR: 240629 MFC after: 1 month === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mail

Re: head -r355027 cross build for powerpc64 (system-clang-9 and devel/binutils@powerpc64 based) linker fails: undefined reference to lldb_private::formatters::CMTimeSummaryProvider

On 2019-Nov-23, at 04:14, Mark Millard wrote: > This is an ELFv1 context, not ELFv2, despite the system-clang-9 basis. > > --- lldb.full --- > /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: > /usr/obj/powerpc64vtsc_clang_altbinutils/powerpc.powerpc64/usr/src/powerpc.powe

Re: head -r355027 context, poudiere jail constructions with the likes of -a arm64.aarch64 -x : awk: can't open file /sys/param.h

[In part this note shows that the issue is not specific to cross builds: -a arm64.aarch64 is not essential. But it also shows just where the /sys/param.h comes from.] On 2019-Nov-24, at 15:22, Mark Millard wrote: > On 2019-Nov-24, at 15:11, Ben Woods wrote: > >> On Sun, 24 Nov 201

Re: [Bug 239813] Update lang/gcc9, lang/gcc9-devel, lang/gcc8, and lang/gcc8-devel to ELFv2 ABI on powerpc64

On 2019-Nov-19, at 20:14, Mark Millard via freebsd-ppc wrote: > On 2019-Nov-19, at 19:58, Mark Linimon wrote: > >>> devel/freebsd-gcc6 >>> devel/freebsd-gcc6@aarch64 >> >> These two ports are exactly equivalent. >> >> I did not have enou

Re: head -r355027 context, poudiere jail constructions with the likes of -a arm64.aarch64 -x : awk: can't open file /sys/param.h

On 2019-Nov-24, at 15:11, Ben Woods wrote: > On Sun, 24 Nov 2019 at 1:27 pm, Mark Millard wrote: > My poudiere jail constructions with the likes of -a arm64.aarch64 -x are > all getting: > > awk: can't open file /sys/param.h > source line number 1 > > Hi M

head -r355027 context, poudiere jail constructions with the likes of -a arm64.aarch64 -x : awk: can't open file /sys/param.h

/os-release was established, possibly via the distrib-dirs distribution DB_FROM_SRC=1 use involved in (re-)constructing /usr/obj/DESTDIRs/clang-cortexA53-installworld-poud/ . === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___

Re: head -r355027 cross build for 32-bit powerpc (system-clang-9 and devel/binutils@powerpc64 based): lots of 'bss-plt forced due to'

On 2019-Nov-23, at 04:56, Mark Millard wrote: > The clang code generation and secure-plt handling and binutils ld handling > do not match (ELFv1 anyway) but the modern ld no longer seems to exit with > an error code for this context so none of the below stopped the build. (I'v

head -r355027 cross build for 32-bit powerpc (system-clang-9 and devel/binutils@powerpc64 based): lots of 'bss-plt forced due to'

local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to snd_uaudio.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to snd_hda.kld /usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to ufs.kld === Mark Millard marklmi at yahoo.com ( dsl-only.net

head -r355027 cross build for powerpc64 (system-clang-9 and devel/binutils@powerpc64 based) linker fails: undefined reference to lldb_private::formatters::CMTimeSummaryProvider

sd.confs.mk /usr/src/share/mk/bsd.files.mk /usr/src/share/mk/bsd.dirs.mk /usr/src/share/mk/bsd.incs.mk /usr/src/share/mk/bsd.links.mk /usr/src/share/mk/bsd.man.mk /usr/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.mk /usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.

Re: [Bug 239813] Update lang/gcc9, lang/gcc9-devel, lang/gcc8, and lang/gcc8-devel to ELFv2 ABI on powerpc64

r the default (or literal native here) testable: .if ${FLAVOR} != native So adding an extra flavor as a default could allow for generating an error? Thanks for the note. It helped me understand what to expect and what to watch out for. === Mark Millard m

Re: [Bug 239813] Update lang/gcc9, lang/gcc9-devel, lang/gcc8, and lang/gcc8-devel to ELFv2 ABI on powerpc64

On 2019-Nov-19, at 11:19, John Baldwin wrote: > On 11/19/19 10:34 AM, Mark Millard wrote: >> [A similar question to the below exists for base/gcc . The lang/gcc* are >> being ELFv2 enabled for powerpc64 by checking the environment for if it is >> new enough and a

Fwd: [Bug 239813] Update lang/gcc9, lang/gcc9-devel, lang/gcc8, and lang/gcc8-devel to ELFv2 ABI on powerpc64

||ELFv2 ABI on powerpc64 --- Comment #38 from Gerald Pfeifer --- (In reply to Mark Millard from comment #35) > I do not know the intent for devel/powerpc64-gcc relative > to future ELFv2 ABI use. Does it need anything? (May be > it is updating to gcc9 or some such first?) Up

Re: svn commit: r511878 - in head/devel: llvm90 llvm90/files/openmp xtoolchain-llvm-devel xtoolchain-llvm90: pkg-static: Unable to access file /wrkdirs/usr/. . ./llvm90/bin/ld:No such file or director

On 2019-Sep-19, at 00:33, Li-Wen Hsu wrote: > On Thu, Sep 19, 2019 at 8:29 AM Mark Millard via freebsd-toolchain > wrote: >> >> [This is from a system-clang 8 based FreeBSD context for >> powerpc64 [ELFv1], not the usual gcc 4.2.1 based context.] >> >>

Re: svn commit: r511878 - in head/devel: llvm90 llvm90/files/openmp xtoolchain-llvm-devel xtoolchain-llvm90: pkg-static: Unable to access file /wrkdirs/usr/. . ./llvm90/bin/ld:No such file or directo

ain-llvm90 =>> Cleaning up wrkdir ===> Cleaning for xtoolchain-llvm90-0.2 build of devel/xtoolchain-llvm90 | xtoolchain-llvm90-0.2 ended at Wed Sep 18 20:08:59 PDT 2019 build time: 00:01:42 !!! build failure encountered !!! === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in ea

Re: runnning after linking without -Wl,-rpath=/usr/local/lib/gcc9 : ld-elf.so.1: . . . : Undefined symbol "__floatunditf@GCC_4.2.0" (possibly arm specific)

On 2019-Sep-6, at 23:29, Mark Millard wrote: > When I built a fairly simple C++17 program (not FreeBSD specific) > (targeting aarch64) with g++9 and then tried to run it, running > reported (I omit a very long file path/name that I was using): > > ld-elf.so.1: . . . : U

runnning after linking without -Wl,-rpath=/usr/local/lib/gcc9 : ld-elf.so.1: . . . : Undefined symbol "__floatunditf@GCC_4.2.0"

d its source are not ready for any distribution.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscr

Re: linker not using make.conf

xec/gcc9/gcc/x86_64-portbld-freebsd13.0/9.2.0/:/usr/local/libexec/gcc9/gcc/x86_64-portbld-freebsd13.0/:/usr/local/lib/gcc9/gcc/x86_64-portbld-freebsd13.0/9.2.0/:/usr/local/lib/gcc9/gcc/x86_64-portbld-freebsd13.0/:/usr/local/lib/gcc9/gcc/x86_64-portbld-freebsd13.0/9.2.0/../../../../../x86_64-portbld-freeb

FreeBSD-head-amd64-gcc builds are broken since 2019-Aug-17 or so: no previous declaration for '__ashldi3' (stand/i386/boot2 context)

rior build was for -r351133 and it built okay. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, sen

head -r351178 amd64->powerpc (32-bit) cross build using devel/xtoolchain-llvm90: "ld: error: symbol '_ThreadRuneLocale' has no type"

deadlocks and cycles nooptions WITNESS_SKIPSPIN# Don't run witness on spinlocks for speed nooptions DIAGNOSTIC nooptions MALLOC_DEBUG_MAXZONES # Separate malloc(9) zones # Avoid dynamic loads? device filemon device geom_label device mac_n

amd64 head -r351153 self-built but via devel/llvm90: 'objcopy: elf_update() failed: Layout constraint violation' for gptboot.bin

src/share/mk/bsd.clang-analyze.mk /usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk /usr/src/share/mk/bsd.sys.mk' .PATH='. /usr/src/stand/i386/gptboot /usr/src/stand/i386/boot2 /usr/src/stand/i386/common /usr/src/stand/libsa' 1 error === Mark Millard marklmi at yahoo.com (

head -r351153 amd64 upgrade installworld failure: realinstall_subdir_stand got: 'sh: cc: not found' (a race?)

--- realinstall_subdir_tests --- . . . --- realinstall_subdir_stand --- sh: cc: not found Repeating buildworld buildkernel and then trying installworld (without the -j28 I had used originally) completed. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar

My 1st head -r351102 amd64->powerpc64 cross-build via devel/llvm90 failed, but it may be just operator error

lang (via system). . . # .if ${.MAKE.LEVEL} == 0 CC=/usr/bin/clang CXX=/usr/bin/clang++ CPP=/usr/bin/clang-cpp .export CC .export CXX .export CPP .endif It may well be that the use of some of llvm-as, llvm-ar, llvm-nm, llvm-objcopy, llvm-objdump, llvm-ranlib, llvm-size, and llvm-strings is

head -r351102 amd64 rebuilding itself but via devel/xtoolchain-llvm90 ( rc2: ports head -r509054 ) fails for boot2.out: ld.lld: error: undefined symbol: __ashldi3

dir.mk /usr/src/share/mk/bsd.sys.mk' .PATH='. /usr/src/stand/i386/boot2' 1 error FYI: # uname -apKU FreeBSD FBSDFHUGE 13.0-CURRENT FreeBSD 13.0-CURRENT #29 r351102M: Thu Aug 15 14:22:00 PDT 2019 markmi@FBSDFHUGE:/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/sys/GENERIC-NODBG

Re: devel/llvm90 requires math/z3 first; building math/z3 requires a c++ toolchain be in place

[I found that the vintage of cmake matters: 3.12 and earlier work differently. Details later.] On 2019-Aug-7, at 14:37, Mark Millard wrote: > On 2019-Aug-7, at 13:58, Brooks Davis wrote: > >> On Wed, Aug 07, 2019 at 01:42:26PM -0700, Mark Millard wrote: >>> >>>

Re: devel/llvm90 requires math/z3 first; building math/z3 requires a c++ toolchain be in place

On 2019-Aug-7, at 13:58, Brooks Davis wrote: > On Wed, Aug 07, 2019 at 01:42:26PM -0700, Mark Millard wrote: >> >> >> On 2019-Aug-7, at 12:56, Brooks Davis wrote: >> >>> On Wed, Aug 07, 2019 at 11:55:04AM -0700, Mark Millard wrote: >>>>

Re: devel/llvm90 requires math/z3 first; building math/z3 requires a c++ toolchain be in place

On 2019-Aug-7, at 12:56, Brooks Davis wrote: > On Wed, Aug 07, 2019 at 11:55:04AM -0700, Mark Millard wrote: >> >> >> On 2019-Aug-7, at 11:02, Brooks Davis wrote: >> >>> On Wed, Aug 07, 2019 at 05:17:14PM +, Brooks Davis wrote: >>>>

Re: devel/llvm90 requires math/z3 first; building math/z3 requires a c++ toolchain be in place

On 2019-Aug-7, at 11:02, Brooks Davis wrote: > On Wed, Aug 07, 2019 at 05:17:14PM +, Brooks Davis wrote: >> On Tue, Aug 06, 2019 at 09:22:52PM -0700, Mark Millard wrote: >>> [I found something known to be missing in the >>> in at least some version

Re: devel/llvm90 requires math/z3 first; building math/z3 requires a c++ toolchain be in place

[I found something known to be missing in the in at least some versions of llvm/cmake/modules/CrossCompile.cmake that messes up the overall handling of LLVM_ENABLE_Z3_SOLVER .] On 2019-Aug-6, at 20:23, Mark Millard wrote: > On 2019-Aug-6, at 19:08, Brooks Davis wrote: > >> On

Re: devel/llvm90 requires math/z3 first; building math/z3 requires a c++ toolchain be in place

On 2019-Aug-6, at 19:08, Brooks Davis wrote: > On Tue, Aug 06, 2019 at 05:59:21PM -0700, Mark Millard wrote: >> >> >> On 2019-Aug-6, at 09:55, Brooks Davis wrote: >> >>> I'd prefer to disable this dependency. There's a knob that worked i

Re: devel/llvm90 requires math/z3 first; building math/z3 requires a c++ toolchain be in place

[This note is not for Brooks and I'm not sending directly to him. It is for others that may be exploring before his "either/or" is figured out for general builds.] On 2019-Aug-6, at 19:04, Mark Millard wrote: > On 2019-Aug-6, at 17:59, Mark Millard wrote: > > >

Re: devel/llvm90 requires math/z3 first; building math/z3 requires a c++ toolchain be in place

On 2019-Aug-6, at 17:59, Mark Millard wrote: > On 2019-Aug-6, at 09:55, Brooks Davis wrote: > >> I'd prefer to disable this dependency. There's a knob that worked in >> the 8.0 timeframe, but the lit build now autodetects z3 when it is >> present and I&#

Re: devel/llvm90 requires math/z3 first; building math/z3 requires a c++ toolchain be in place

.so.7 (0x800242000) This makes clear that mixing in libstdc+++ or the like would likely not be appropriate unless llvm90 was also using such. So a default gcc based build of libz3.so likely would not be appropriate if llvm90 is to also be built such that it can bind to libz3.so if found. > On Mon

devel/llvm90 requires math/z3 first; building math/z3 requires a c++ toolchain be in place

know the details.) For architectures still at gcc/g++ 4.2.1, some alternate c++ tool chain needs to be used to build libz3.so but the result needs to be compatible with llvm90 later using the libz3.so's content. (I do not know the details.) === Mark Millard marklmi at yahoo.com ( dsl-onl

Attempted buildworlds via devel/llvm90 failed for: undefined symbol: bcmp / undefined reference to `bcmp'

powerpc.powerpc64/libexec/rtld-elf/rtld_libc.a(strstr.nossppico): in function `twoway_strstr': /usr/src/lib/libc/string/strstr.c:121: undefined reference to `bcmp' === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) _

devel/llvm90 based buildworld: lots of notices of "OMP: Info #270: omp_set_nested routine deprecated, please use omp_set_max_active_levels instead"

7;OMP: Info #' /root/sys_typescripts/typescript_make_powerpc64vtsc_nodebug_incl_clang_xtoolchain-llvm-amd64-host-2019-08-05:18:34:34 | wc 26534 265334 2600253 === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) _

Re: amd64->armv7 cross build: devel/llvm90 build blocked by math/z3 build failure: can't create dynamic relocation R_ARM_MOVW_ABS_NC against symbol: __stack_chk_guard in readonly segment

On 2019-Aug-5, at 14:48, Mark Millard wrote: [Note: Targeting aarch64 instead did not have this problem.] > > [00:03:02] [02] [00:00:00] Building math/z3 | z3-4.8.5_1 > . . . > [00:06:31] [02] [00:03:29] Saved math/z3 | z3-4.8.5_1 wrkdir to: > /usr/local/poudrie

amd64->armv7 cross build: devel/llvm90 build blocked by math/z3 build failure: can't create dynamic relocation R_ARM_MOVW_ABS_NC against symbol: __stack_chk_guard in readonly segment

dll/install_tactic.o:(install_tactics(tactic_manager&)) Is the default: STATIC=on: Build static z3 library inappropriate for armv7? === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-toolchain@freebsd.

system-clang system-lld used to amd64->powerpc (32-bit) cross-build: lld with "-m" "elf32ppc_fbsd" is not enough to allow --secure-plt

erpc.powerpc/tmp/usr/lib/crtn.o" Executing the full reported "/usr/bin/ld" produces: ld: error: unknown argument: --secure-plt So "-m" "elf32ppc_fbsd" was insufficient to enable allowing --secure-plt (a powerpc 32-bit specific option). === Mark Millard markl

system-clang devel/powerpc64-binutils used to amd64->powerpc (32-bit) cross-build vs. the ld's secture-plt criteria: leads to build failure

erpc.powerpc/usr/src/powerpc.powerpc/tmp/usr/lib/libgcc.a(umoddi3.o) Using bss-plt due to accf_http.kld Using bss-plt due to acl_nfs4.kld Using bss-plt due to acl_posix1e.kld Using bss-plt due to if_ae.kld Using bss-plt due to if_age.kld Using bss-plt due to reloc.o The coverage of buildkernel is i

Re: head -r347549 installworld targeting amd64 after debug build: "stand/efi/boot1 (install)" tried to cc ... -o boot1.sym.full ... and got cc: not found

On 2019-Jun-18, at 16:23, Bryan Drewery wrote: > On 6/18/2019 3:55 PM, Mark Millard wrote: >> [I'm back at -r347549 because of other on-going investigations >> that started back then.] >> >> I normally do non-debug -jN builds but had a reason to make >> a

head -r347549 installworld targeting amd64 after debug build: "stand/efi/boot1 (install)" tried to cc ... -o boot1.sym.full ... and got cc: not found

ET 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

Re: kern_execve using vm_page_zero_invalid but not vm_page_set_validclean to load /sbin/init ?

[Looks to me like the ->valid mask only is used for the last page of the /sbin/init file, not based on the size and alignment of the data requested for the PT_LOAD.] On 2019-Jun-11, at 21:53, Mark Millard wrote: > [The garbage after .got up to the page boundary is > .comment sectio

Re: kern_execve using vm_page_zero_invalid but not vm_page_set_validclean to load /sbin/init ?

[The garbage after .got up to the page boundary is .comment section strings. The context here is targeting 32-bit powerpc via system-clang-8 and devel/powerpc64-binutils for buildworld and buildkernel . ] On 2019-Jun-11, at 19:55, Mark Millard wrote: > [I have confirmed .sbss not being zer

crash of 32-bit powerpc -r347549 kernel built via system-clang-8, _init_tls is where the initial DIAGNOSTICS-reported SIGSEGV happens

ng pid 1 tid 12 td 0x1506ae0 0xd6b7c950: at cursig+0x55c 0xd6b7ca10: at ast+0x508 0xd6b7ca40: user DSI read trap @ 0x1c20 by 0x1812f74: srr1=0xd032 r1=0xde90 cr=0x2000 xer=0 ctr=0 sr=0x4000 frame=0xd6b7ca48 db> The "trap @" val

Re: crash of 32-bit powerpc -r347549 kernel built via system-clang-8 (crash is while trying to mount the root file system) [debug kernel case: code generation error] [I was wrong]

[I misanalysed the code. Sorry for the noise.] On 2019-Jun-5, at 14:17, Mark Millard wrote: > [This is from my experiments with more modern toolchains than > normally/offocially used, specifically for 32-bit powerpc this > time.] > > On 2019-Jun-5, at 01:35, Mark Millard wrote

Re: crash of 32-bit powerpc -r347549 kernel built via system-clang-8 (crash is while trying to mount the root file system) [debug kernel case: code generation error]

[This is from my experiments with more modern toolchains than normally/offocially used, specifically for 32-bit powerpc this time.] On 2019-Jun-5, at 01:35, Mark Millard wrote: > On 2019-Jun-3, at 19:40, Mark Millard wrote: > >> On 2019-Jun-3, at 17:24, Mark Millard wrote: >

  1   2   3   4   5   6   7   8   9   >