I've been using USE_TMPFS=yes (so "wrkdir data") on
various systems, both ZFS (recently) and UFS
(generally, even now). Only one system builds rust
(in order for something else to be built), at least
so far.
An example of the wrkdirs tmpfs use for rust is
(UFS context):
# df -m | grep tmpfs
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.
> Default target:
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.
Default target: aarch64-portbld-freebsd14.0
Host CPU: (unknown)
Registered
My context: head ( currently at -r363590 )
man src.conf is explicit that WITHOUT_OPENMP is the default for
aarch64 (for example).
But I note that https://openmp.llvm.org/README.txt says:
(it has the more detailed breakdown of OS/compiler combinations
for architectures where it matters)
QUOTE
In a aarch64 head -r363590 context with g++9 from ports
in use (so ffsl is only compiler-defined outside strict
ISO modes) . . .
I got a compile failure for using CPU_FFS because ffsl
"was not declared". My code was being compiled via
-std=c++17 . (Other than enabling one feature, it is
not
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 point support code for aarch64).
>>
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 system libraries and such
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 system libraries and such looks
like:
. . .
CXX+= -Wno-psabi -nostdinc
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'm
>>> unaware of. (I sometimes
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
>> to see what the current
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 operator should be either == or !=
>> make[2]:
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 operator should be either == or !=
make[2]: "/usr/src/share/mk/bsd.compiler.mk" line 197: warning: String
comparison operator
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
>> to see what the current
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
to see what the current status is for such use.)
In attempting to buildworld buildkernel via
powerpc-unknown-freebsd13.0-gcc9
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
to see what the current status is for such use.)
In attempting to buildworld buildkernel via
powerpc64-unknown-freebsd13.0-gcc9
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
to see what the current status is for such use.)
I attempted to build a system for 32-bit powerpc using clang
and binutils,
[Ports was at -r528828 so this did not check
-r531601 update to 5.14.2 of Qt5.]
This is based on worlds built via WITHOUT_BINUTILS= .
I was checking to see how things are for "[o]ne of the goals of
this process [ExternalGCC] is to deprecate and remove the old
GCC 4.2.1 and binutils 2.17.50 in
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++' when in C++ mode, this behavior is
While trying to build base/gcc6 on aarch64 (implicitly targeting aarch64:
self hosted), it failed with:
. . .
c++: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is
deprecated [-Wdeprecated]
For reference:
--- lldb.full ---
ld: error: undefined symbol:
lldb_private::formatters::CMTimeSummaryProvider(lldb_private::ValueObject&,
lldb_private::Stream&, lldb_private::TypeSummaryOptions const&)
>>> referenced by ObjCLanguage.cpp
>>> ObjCLanguage.o:(.toc+0x18) in archive
I've tracked applying Roman Divacky's patch below
for powerpc for nearly 3 years. (I had to follow
some restructuring and the below is from a base of
head -r358510 .) The patch never made it into a
llvm/clang update that I've seen.
# svnlite diff
There is a review on llvm.org for having clang match the gcc/g++ ABI
used for powerpc64 FreeBSD for what is now a known mismatch (at least
for clang 9 as it is for ELFv2):
https://reviews.llvm.org/D73290
In essence, clang 9 is using -maix-struct-return (stack space and a
pointer to it) which
[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
> referenced by ofw_syscons.c
>
[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: dflt_font_14
referenced by
--- kernel.full ---
ld: error: undefined symbol: dflt_font_8
>>> referenced by ofw_syscons.c
>>> ofw_syscons.o:(.toc+0x10)
ld: error: undefined symbol: dflt_font_14
>>> referenced by ofw_syscons.c
>>> ofw_syscons.o:(.toc+0x18)
ld: error: undefined symbol: dflt_font_16
system-clang (C) handles returning example struct based on it
being on the stack (-maix-struct-return style); gcc9 via
registers r3 and r4 (-msvr4-struct-return style). So this
somewhat tracks what was observed for the C++ ABI.
The evidence from on a old G4 PowerMac3,6 . . .
The source code:
#
[So far I have not checked if there is a
somewhat analogous C (not C++) issue or
not for gcc9 . For C++, when registers are
used vs. when stack space is used does not
always match system-clang++ for g++9
targeting 32-bit powerpc.]
Building on a head -r356426 32-bit powerpc
the following program:
This is based on testing artifact.ci.freebsd.org
32-bit powerpc materials on some (2 socket) G5s.
It is the later FreeBSD head revision that causes
an earlier boot-failure than the other one that I
recently reported.
There are no 32-bit powerpc artifacts between
-r356109 and -r356118
John Baldwin jhb at FreeBSD.org wrote on
Thu Jan 2 21:41:07 UTC 2020 :
> On 1/2/20 1:34 PM, John Baldwin wrote:
> > Author: jhb
> > Date: Thu Jan 2 21:34:44 2020
> > New Revision: 356289
> > URL: https://svnweb.freebsd.org/changeset/base/356289
> >
> > Log:
> > Look for cross toolchain
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 alternate kernels a little
>> shows. . .
>>
>>
>>
>>
My cross-build attempts were failing to build
ld.bfd for use for building LIB32 for powerpc64
until I made the following change:
# svnlite diff gnu/usr.bin/binutils/Makefile
Index: gnu/usr.bin/binutils/Makefile
===
---
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/${BU_PREFIX}-ld
>>
>> The likes of
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 be used to work around the issue; I strongly
>>> recommend
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):
>
> /boot/kernel/kernel: file format
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):
/boot/kernel/kernel: file format elf32-powerpc-freebsd
/boot/kernel/kernel
architecture: powerpc:common,
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.full] Error code 1
(There are later notes below with build failure
information that lead me to try devel/binutils@powerpc .)
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
I ran into the following ubounded loop
(via the continue) in bfd/elf64-ppc.c
while trying to do a
devel/freebsd-gcc9@powerpc64 based
buildworld buildkernel :
/* Read the relocations. */
relstart = _bfd_elf_link_read_relocs (ibfd, sec, NULL, NULL,
There are two nearly 100% cpu usage instances of
powerpc64-unknown-freebsd13.0-ld , each with over
480 cpu minutes, one for clang.full and one for
lld.full . (amd64->powerpc64 cross build.)
The below shows the file system view of the status
after all that time: 0 size .full files.
# ls -ldTt
I have historically used the likes of:
# grep -r no-threads /etc/
/etc/make.conf:LDFLAGS.lld+= -Wl,--no-threads
But in trying to build for powerpc64 there is some
32-bit linking as well and it gets the above
involved despite the .lld in the notation. LDFLAGS.lld
being involved at all for a
Is system-clang 9.0.1 supposed to implicitly try to use
/usr/local/bin/as ? It does for this context . . .
Note the -fno-integrated-as use in the later quoted log material.
I'll also note that an experiment via -### shows that system-clang
9.0.1 then uses a command like (from a very simple
In attempting a devel/aarch64-none-elf-gcc build (in a
amd64->armv7 cross-build context), it failed with:
===
===> Building package for aarch64-none-elf-gcc-6.4.0_7
pkg-static: Unable to access file
In a 32-bit powerpc environment (head -r356066 or so, clang based), I
attempted to "make package" (not a cross build) for
/usr/ports/base/binutils ( as of ports -r520539 ) and the end result
was failures to find 64-bit ldscripts:
===> Building package for freebsd-binutils-2.33.1
pkg-static:
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):
>
> I maintain this is a
Context: devel/freebsd-gcc* (for example)
using:
--with-as=${LOCALBASE}/bin/${BU_PREFIX}-as \
--with-ld=${LOCALBASE}/bin/${BU_PREFIX}-ld
The likes of ${BU_PREFIX}-ld possibly also
exists someplace else on the path in use.
So I suggest that the BUILD_DEPENDS and
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):
>
>
>
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-powerpc/gcc-9.2.0/gcc/tree-vect-loop.c:4595:12:
error: expected unqualified-id
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.
>
> ===> lib/csu/powerpc64
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.
===> lib/csu/powerpc64 (all)
Building
/usr/src/sys/arm64/arm64/locore.S: Assembler messages:
/usr/src/sys/arm64/arm64/locore.S:282: Error: unknown or missing system
register name at operand 2 -- `mrs x2,icc_sre_el2'
/usr/src/sys/arm64/arm64/locore.S:285: Error: unknown or missing system
register name at operand 1 -- `msr
As this avoided using system-clang (or any clang), the -secure-plt leading
to bss-plt being forced issue for 32-bit powerpc appears to *NOT* be
clang-specific at all!
I was just curious to see what would be reported. (The system-clang
and devel/binutils@powerpc combination completed buildworld
On 2019-Dec-18, at 13:48, John Baldwin wrote:
> In the interest of supporting newer versions of GCC for a base system
> toolchain, I've renamed the external GCC packages from -gcc
> to -gcc6. These are built as flavors of a new devel/freebsd-gcc6
> port. The xtoolchain package is not used
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_stand ---
> btxld -v -E
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_stand ---
btxld -v -E 0x2000 -f bin -b
/base/head/share/man/man5/src.conf.5 :
-r353933 show 10 matches to "power" (case independent).
-r353358 shows 244 matches to "power" (case independent).
In head -r355644 I got the following:
# man src.conf | grep -i power
Set to not build LLVM target support for PowerPC. The
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:
>
[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 2019 at 1:27
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 enough time before the commit to puzzle out a way to
>>
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,
>
> I have been getting
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
If /sys is supposed to be something like:
# ls -ld /sys
lrwxr-xr-x 1 root wheel 11 May 21 2018 /sys -> usr/src/sys
then the path would appear 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've
> no clue if
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 enough time before the commit to puzzle out a way to
> work around that. I have limited understanding of flavors.
>
> The way it
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 already is ELFv2 based.]
>>
[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 already is ELFv2 based.]
Begin forwarded message:
From: bugzilla-nore...@freebsd.org
Subject: [Bug 239813] Update lang/gcc9,
[This is from a system-clang 8 based FreeBSD context for
powerpc64 [ELFv1], not the usual gcc 4.2.1 based context.]
In attempting to update the ports I normally build, jumping
ahead from -r509171 to ports head -r512281, I got the
following in the poudriere-devel bulk build:
. . .
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: . . . : Undefined symbol
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: . . . : Undefined symbol "__floatunditf@GCC_4.2.0"
# ldd . . .
. . .:
On 2019-Sep-4, at 11:35, Sid wrote:
> When the base linker is not available, the link needs to be from /usr/bin/ld
> rather than from /usr/local/*/ to /usr/local/bin/ld.lld80 or variant of that.
> Also, programs being compiled do look for /usr/bin/ld or maybe another ld
> under
https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/11176/console
is for -r351411 and shows:
15:43:33
--- ashldi3.o ---
15:43:33
/usr/local/bin/x86_64-unknown-freebsd12.0-gcc
--sysroot=/tmp/obj/workspace/src/amd64.amd64/tmp
-B/usr/local/x86_64-unknown-freebsd12.0/bin/ -O2 -pipe
I decided to see what would happen if I tried a
32-bit powerpc buildworld buildkernel (cross
build) based on using devel/llvm90 (after the rc2
update). Where and how it stopped is shown below.
(Note the reference to clang-9 as well.)
--- all_subdir_usr.bin ---
--- apply.full ---
ld: error: symbol
I upgraded to head -r351153 and then attempted a buildworld
buildkernel via devel/llvm90 (rc2 via ports head -r509054),
but that (from scratch) build attempt got:
--- gptboot.bin ---
objcopy: elf_update() failed: Layout constraint violation
*** [gptboot.bin] Error code 1
make[5]: *** gptboot.bin
The below installworld material was after an apparently successful
buildworld buildkernel then installkernel . Wrong stage for a cc
producing loader_lua.sym ? (This was a normal, system-clang based
build context, attempting an upgrade from head -r351102 .)
--- realinstall_subdir_stand ---
cc
My first attempt to cross buildworld buildkernel amd64->powerpc64
via devel/llvm90 without involving devel/powerpc64-binutils (or
other such) failed with:
--- gnu/lib/libssp/libssp_nonshared__PL ---
/usr/local/llvm90/bin/llvm-ranlib: error: Exactly one archive should be
specified.
OVERVIEW:
[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 12:56,
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 11:02, Brooks Davis
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 Tue, Aug 06, 2019 at 09:22:52PM -0700, Mark
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 versions of
>>>
[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 Tue, Aug 06,
[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:
>
>
>
>>> . . .
>>
>>
bc++.so.1 (0x8020e4000)
>libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x800738000)
>libm.so.5 => /lib/libm.so.5 (0x80075a000)
>libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x80078c000)
>libc.so.7 => /lib/libc.so.7 (0x800242000)
>
> This makes clear that m
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
Building math/z3 involves:
# grep compiler /usr/ports/math/z3/Makefile
USES= compiler:c++11-lang python:2.7,build
But devel/llvm90 requires math/z3 to have been built before
devel/llvm90 is built:
# pkg info -d llvm90
llvm90-9.0.0.r1:
libxml2-2.9.9
z3-4.8.5_1
amd64 (self hosted):
--- all_subdir_libexec ---
ld: error: undefined symbol: bcmp
>>> referenced by strstr.c:121 (/usr/src/lib/libc/string/strstr.c:121)
>>> strstr.nossppico:(strstr) in archive
>>>
After building devel/llvm90 on amd64 I started a buildworld buildkernel
based on it (amd64 self-hosted).
It is producing thousands of notices:
OMP: Info #270: omp_set_nested routine deprecated, please use
omp_set_max_active_levels instead.
It is still building but at this point:
# grep 'OMP:
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:
>
[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/poudriere/data/wrkdirs/FBSDFSSDjailArmV7-default/default/z3-4.8.5_1.tar
[00:06:31] [02]
Sometime at or before head -r349444 my historical src.conf variant
that I use to attempt amd64->powerpc cross-build to using system-ld
(lld) started reporting:
--- buildworld ---
make[1]: "/usr/src/Makefile.inc1" line 347: SYSTEM_COMPILER: Determined that
CC=cc matches the source tree. Not
Sometime at or before head -r349444 my historical src.conf variant
that i use to amd64->powerpc cross-build using devel/powerpc64-binutils
stopped working, getting:
--- libc.so.7.full ---
building shared library libc.so.7
/usr/local/powerpc64-unknown-freebsd13.0/bin/ld: bss-plt forced due to
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 debug build for amd64 to be installed
[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 debug build for amd64 to be installed and booted (head
-r347549 ). But it is failing with the below. The
buildworld did not report and issues in
[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 section strings.
[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 zero'd
The failure is related to *sp++ in the
below source code from lib/libc/gen/tls.c .
extern char **environ;
void
_init_tls(void)
{
#ifndef PIC
Elf_Addr *sp;
Elf_Auxinfo *aux, *auxp;
Elf_Phdr *phdr;
size_t phent, phnum;
int i;
void *tls;
sp
[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:
>
>> On
[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 tried
[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
catch the /tmp/* material from:
[I adjusted the Subject line to give more context.]
[/usr/local/lib/qt5/bin/qlalr and /usr/local/lib/qt5/libQt5Core.so.5
overall use each of the following (somewhat indirectly) in my
system-clang-8-based powerpc64 context:
/usr/local/lib/gcc8/libstdc++.so.6
/usr/lib/libc++.so.1
/lib/libcxxrt.so.1
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 frontend command failed due to signal
1 - 100 of 241 matches
Mail list logo
