MPFS 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)
_
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.
>
-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 yahoo.com
( dsl-only.net went
|
--||--|
| 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
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.com
( dsl-on
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 floating poi
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 s
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 at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
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 that I'
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 use
>&
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
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
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 use
>&
.mk
/usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk
/usr/src/sys/conf/kern.mk'
.PATH='. /usr/src/sys/modules/iflib /usr/src/sys/net
/usr/obj/powerpcvtsc_xtoolchain-gcc/powerpc.powerpc/usr/src/powerpc.powerpc/sys/GENERICvtsc-NODBG'
1 error
===
Mark Millard
marklmi at yahoo.com
(
0 */
"3:\n\t"
: "=" (ret), "=m" (*p), "+" (tmp)
: "r" (p), "r" (cmpval), "r" (newval), "m" (*p),
"r" (mask)
: "cr0",
/src/share/mk/bsd.sys.mk'
.PATH='. /usr/src/usr.bin/gh-bc /usr/src/contrib/bc/src /usr/src/contrib/bc/gen
/usr/src/contrib/bc/manuals
/usr/obj/powerpcvtsc_clang_altbinutils/powerpc.powerpc/usr/src/powerpc.powerpc/usr.bin/gh-bc'
1 error
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in e
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 Millard
markl
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 as 'c++
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 to "freebsd-tool
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
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)
__
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).
===
Mark Millard
marklmi
[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
[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 sym
t;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 and another of which worked with
vt but not sc.
I build with bo
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
r --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
c1a0a213378a458fbea1a5c77b315c7dce08fd05) (based
en_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,r0,0x0
db
(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)
___
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
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
(
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
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
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
/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
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.
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
/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}
===
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 use
/gen /usr/src/stand/powerpc/boot1.chrp'
1 error
===
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
ad 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
Revision: 5205
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
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
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_s
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
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
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 2018-Mar
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.
>
ore_init.c:100:1: internal compiler error: in
rs6000_pltseq_template, at config/rs6000/rs6000.c:21873
100 | }
| ^
no stack trace because unwind library not available
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructi
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)
___
freebsd-toolchain@freebsd.org mailing list
ict'
'-Wno-error=sizeof-pointer-memaccess' '-Wno-error=stringop-truncation' '-v'
'-I' '/usr/src/lib/csu/powerpc' '-D' 'SHARED' '
-fpic' '-c' '-o' 'crtbeginS.o'
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-tool
efault 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 base/gcc ? Is their (future?) status
changed b
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
-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
.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
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
[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
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 e
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 Mark,
elease
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)
___
f
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've
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
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
to
||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?)
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
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
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 unsubscribe,
_64-portbld-freebsd13.0/9.2.0/../../../../../x86_64-portbld-freebsd13.0/bin/
LIBRARY_PATH=/usr/local/lib/gcc9/gcc/x86_64-portbld-freebsd13.0/9.2.0/:/usr/local/lib/gcc9/gcc/x86_64-portbld-freebsd13.0/9.2.0/../../../../../x86_64-portbld-freebsd13.0/lib/:/usr/local/lib/gcc9/gcc/x86_64-portbld-freebsd13.0/9.
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, send any mail
filemon
device geom_label
device mac_ntpd
# more ~/src.configs/make.conf
CFLAGS.gcc+= -v
LDFLAGS.lld+= -Wl,--no-threads
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-toolchain@freeb
/i386/common /usr/src/stand/libsa'
1 error
===
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
.a
--- 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
objdump, llvm-ranlib,
llvm-size, and llvm-strings is not intended. But I've
not seen a description of the intent.
(My build with devel/powerpc64-binutils involved
completed just fine.)
For reference, devel/llvm90 here is based on ports head
-r509054 providing rc2 of llvm90.
===
Mark Mi
[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:
>>>
>>>
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:
>>>>
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:
>>>>
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
[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
[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:
>
>
>
>
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've failed t
at 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, Aug 05, 2019 at 08:45:31PM -0700, Mark
not 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-only.net
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)
___
: 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)
___
freebsd
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
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.org mailing list
https://lists.freebsd.org/ma
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
.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 incomplete because of:
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 debu
ot1.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.
[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
[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
d 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 @" value ca
[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
[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:
>
[I forgot to mention of the combination: gcc and libc++.=
On 2019-May-24, at 12:11, Mark Millard wrote:
> On 2019-May-24, at 11:25, Mark Linimon wrote:
>
>> On Thu, May 23, 2019 at 10:33:35PM -0700, Mark Millard via freebsd-toolchain
>> wrote:
>>> That is no matt
On 2019-May-24, at 11:25, Mark Linimon wrote:
> On Thu, May 23, 2019 at 10:33:35PM -0700, Mark Millard via freebsd-toolchain
> wrote:
>> That is no matter what the system compiler is for powerpc64.
>>
>> This lead to the below mixing of libstdc++.so.6 and libc++/
On 2019-May-24, at 00:10, Ralf Wenk wrote:
> On 2019-05-23, at 12:31 -0700, Mark Millard wrote:
>> On 2019-May-23, at 11:47, Jan Beich wrote:
>>
>>> Mark Millard writes:
>>>
>>>> Unfortunately poudiere bulk tar archives of failures do not
>&
]
On 2019-May-23, at 21:09, Mark Millard wrote:
[Merely adding the extra instruction was not the right idea
for what the problem is.]
On 2019-May-23, at 20:10, Mark Millard wrote:
> [I tried rebuilding things based on a full-bootstrap
> build of lang/gcc8 instead. It made no diff
On 2019-May-23, at 11:47, Jan Beich wrote:
> Mark Millard writes:
>
>> Unfortunately poudiere bulk tar archives of failures do not
>> catch the /tmp/* material from:
>>
>> cc: error: unable to execute command: Abort trap (core dumped)
>> cc: error: clang f
1 - 100 of 694 matches
Mail list logo