On 2020-Apr-29, at 10:22, Emmanuel Vadot wrote:
> On Wed, 29 Apr 2020 12:50:36 +0200
> Emmanuel Vadot wrote:
>
>> On Wed, 29 Apr 2020 01:36:01 -0700
>> Mark Millard wrote:
>>
>>> [Build successes for building via poudriere-devel.
>>> Message history removed.]
>>>
>>> Based on (some
[Build successes for building via poudriere-devel.
Message history removed.]
Based on (some whitespace details might not survive):
# svnlite diff /usr/ports/devel/aarch64-none-elf-gcc/
Index: /usr/ports/devel/aarch64-none-elf-gcc/Makefile
[Looks like more than objdump may be involved for
/usr/local/aarch64-none-elf/bin/ use.]
On 2020-Apr-28, at 14:00, Mark Millard wrote:
> [Found a cause of the poudiere vs. not distinction.]
>
> On 2020-Apr-28, at 13:01, Mark Millard wrote:
>>
>> On 2020-Apr-28, at 09:23, Mark Millard wrote:
[Found a cause of the poudiere vs. not distinction.]
On 2020-Apr-28, at 13:01, Mark Millard wrote:
>
> On 2020-Apr-28, at 09:23, Mark Millard wrote:
>
>> On 2020-Apr-28, at 07:39, Emmanuel Vadot wrote:
>>
>>> On Mon, 27 Apr 2020 20:14:47 -0700
>>> Mark Millard wrote:
>>>
On
On 2020-Apr-28, at 09:23, Mark Millard wrote:
> On 2020-Apr-28, at 07:39, Emmanuel Vadot wrote:
>
>> On Mon, 27 Apr 2020 20:14:47 -0700
>> Mark Millard wrote:
>>
>>> On 2020-Apr-27, at 17:15, Mark Millard wrote:
>>>
On 2020-Apr-27, at 11:46, Emmanuel Vadot wrote:
> On Mon,
On 2020-Apr-28, at 07:39, Emmanuel Vadot wrote:
> On Mon, 27 Apr 2020 20:14:47 -0700
> Mark Millard wrote:
>
>> On 2020-Apr-27, at 17:15, Mark Millard wrote:
>>
>>> On 2020-Apr-27, at 11:46, Emmanuel Vadot wrote:
>>>
On Mon, 27 Apr 2020 12:32:46 +0200
Emmanuel Vadot wrote:
On 2020-Apr-27, at 17:15, Mark Millard wrote:
> On 2020-Apr-27, at 11:46, Emmanuel Vadot wrote:
>
>> On Mon, 27 Apr 2020 12:32:46 +0200
>> Emmanuel Vadot wrote:
>>
>>> On Sun, 26 Apr 2020 12:13:46 -0700
>>> Mark Millard via freebsd-arm wrote:
>>>
On 2020-Apr-26, at 01:14,
It appears that quoting vs. option handling is not
working as the build expects or some odd file
names involved:
libtool: compile: mv -f "-fgnu-runtime.o" ".libs/NXConstStr.o"
mv: illegal option -- g
usage: mv [-f | -i | -n] [-hv] source target
mv [-f | -i | -n] [-v] source ... directory
This was an amd64->aarch64 poudriere-devel based cross build,
using nxb-bin. Ports head -r533162 .
It looks like it expects the (nxb-bin based) cc to automatically
look in /usr/local/lib/ (or wherever) for finding some matches to
-lNAME but things were not set up for that to happen. It may need
On 2020-Apr-27, at 11:46, Emmanuel Vadot wrote:
> On Mon, 27 Apr 2020 12:32:46 +0200
> Emmanuel Vadot wrote:
>
>> On Sun, 26 Apr 2020 12:13:46 -0700
>> Mark Millard via freebsd-arm wrote:
>>
>>>
>>>
>>> On 2020-Apr-26, at 01:14, Mark Millard wrote:
>>>
The below where based on
On 2020-Apr-26, at 01:14, Mark Millard wrote:
> The below where based on poudriere-devel based build attempts.
> /usr/ports/ was based on head -r532972 and aarch64 FreeBSD was
> based on head -r360311 . amd64 FreeBSD did not have the build
> problem for the aaarch64-targeted u-boot ports.
>
The below where based on poudriere-devel based build attempts.
/usr/ports/ was based on head -r532972 and aarch64 FreeBSD was
based on head -r360311 . amd64 FreeBSD did not have the build
problem for the aaarch64-targeted u-boot ports.
The overall build is still going and more aarch64-targeted
On 2020-Apr-25, at 02:00, Emmanuel Vadot wrote:
> On Sat, 25 Apr 2020 10:56:47 +0200
> Emmanuel Vadot wrote:
>
>> On Sat, 25 Apr 2020 00:43:27 -0700
>> Mark Millard via freebsd-uboot wrote:
>>
>>> From the log file:
>>>
>>> ===> Patching for u-boot-rpi4-2020.04
>>> ===> Applying
>From the log file:
===> Patching for u-boot-rpi4-2020.04
===> Applying distribution patches for u-boot-rpi4-2020.04
2 out of 2 hunks failed--saving rejects to
scripts/dtc/libfdt/fdt_addresses.c.rej
*** Error code 1
Details:
amd64 head -r360289 context. Ports head -r532914 context.
#
[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-16, at 21:48, Mark Millard wrote:
> Context: head -r358966 attempting to update ports
> to -r528535 . Also, 50+ ports built just fine
> but the below has been repeatable in my context.
>
> The original failure was under devel/poudriere-devel (with
> nxb-bin/ materials used). But
Context: head -r358966 attempting to update ports
to -r528535 . Also, 50+ ports built just fine
but the below has been repeatable in my context.
The original failure was under devel/poudriere-devel (with
nxb-bin/ materials used). But part of the below is from
exploring with various steps in a
On 2020-Feb-22, at 09:29, Stefan Eßer wrote:
> Am 22.02.20 um 03:50 schrieb Mark Millard via freebsd-ports:
>>
>>
>> . . .
>>
>> In the style of my prior examples (including the change that
>> found libedit and such), analogous would be:
>>
>
On 2020-Feb-21, at 15:59, Kevin Oberman wrote:
> On Fri, Feb 21, 2020 at 8:38 AM Mark Millard via freebsd-ports
> wrote:
> Based on the example from https://www.freebsd.org/cgi/man.cgi?ldd
> there are commands such as the following that might help:
>
> . . .
>
> Th
On 2020-Feb-21, at 08:38, Mark Millard wrote:
> Based on the example from https://www.freebsd.org/cgi/man.cgi?ldd
> there are commands such as the following that might help:
>
> . . .
>
> This can be a lot of files to go through (e.g., lib*) and so
> can take a fair amount of time.
The
Based on the example from https://www.freebsd.org/cgi/man.cgi?ldd
there are commands such as the following that might help:
# find /usr/local/bin* /usr/local/lib* -type f | xargs -n1 file -F ' ' | grep
'ELF.*dynamically' | cut -f1 -d' ' | xargs ldd -f '%A %o\n' | grep
ncurses\.so\.8 | more
On 2020-Feb-17, at 09:56, Mark Millard wrote:
> On 2020-Feb-17, at 09:53, Mark Millard wrote:
>
>> [The native arm64 build worked fine. But the cross builds
>> got . . .]
>>
>> The builds failed with:
>>
>> > Compressing man pages (compress-man)
>> ===> Installing ldconfig
On 2020-Feb-17, at 09:53, Mark Millard wrote:
> [The native arm64 build worked fine. But the cross builds
> got . . .]
>
> The builds failed with:
>
> > Compressing man pages (compress-man)
> ===> Installing ldconfig configuration file
>
[The native arm64 build worked fine. But the cross builds
got . . .]
The builds failed with:
> Compressing man pages (compress-man)
===> Installing ldconfig configuration file
===
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 Mon, Dec 30, 2019 at 3:41 AM Carmel NY wrote:
> > On Sun, 29 Dec 2019 18:51:41 -0700, Adam Weinberger stated:
> > . . .
> > https://www.microsoft.com/en-us/legal/intellectualproperty/mtl/exfat-licensing.aspx
> > >suggests that (a) exFAT is still patented and restricted as before,
> > >and
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,
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
I attempted to build some ports in a 32-bit powerpc
context (via poudriere) and graphics/mesa-libs ended
up being included. The mesa-libs build failed with:
u_atomic.c:38:1: error: cannot redeclare builtin function
'__sync_add_and_fetch_8'
__sync_add_and_fetch_8(uint64_t *ptr, uint64_t val)
^
Context: ports at -r520539. Clang-based FreeBSD.
pqg.c:345:16: error: result of comparison of constant 18446744073709551615 with
expression of type 'unsigned long' is always true
[-Werror,-Wtautological-constant-out-of-range-compare]
if (addend < MP_DIGIT_MAX) {
~~ ^
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
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
[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-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
> Mark Millard writes:
>
> > For some reason security/nss tried to build "-march=armv8-a
> > -mfpu=crypto-neon-fp-armv8 aes-armv8.c"
> > material when targeting armv7 (cortex-a7). This did not go well . . .
>
> ARMv8 isn't limited to 64-bit mode. NSS 3.47 builds fine on 12.0 armv7, see
>
For some reason security/nss tried to build "-march=armv8-a
-mfpu=crypto-neon-fp-armv8 aes-armv8.c"
material when targeting armv7 (cortex-a7). This did not go well . . .
/nxb-bin/usr/bin/cc -o FreeBSD13.0_OPT.OBJ/FreeBSD_SINGLE_SHLIB/aes-armv8.o -c
-O2 -pipe -mcpu=cortex-a7
You may want to contact "jhb": head/base/README says:
QUOTE
# $FreeBSD$
How to cross build initial toolchain
Example with sparc64
1/ install a cross toolchain
pkg install sparc64-xtoolchain-gcc
2/ cross build world
make CROSS_TOOLCHAIN=sparc64-gcc TARGET=sparc64 TARGET_ARCH=sparc64 buildworld
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.]
>>
>> In attempting to update the ports I
On 2019-Sep-18, at 17:25, Mark Millard wrote:
> [This is from a system-clang 8 based FreeBSD context for
> powerpc64, not the usual gcc 4.2.1 based context.]
>
> In attempting to update the ports I normally build, jumping
> ahead from -r509171, I got the following:
>
> . . .
> ...updated
[This is from a system-clang 8 based FreeBSD context for
powerpc64, not the usual gcc 4.2.1 based context.]
In attempting to update the ports I normally build, jumping
ahead from -r509171, I got the following:
. . .
...updated 1359 targets...
019-08-18 09:48, Mark Millard wrote:
>>>> On 2019-Aug-18, at 00:34, Niclas Zeising wrote:
>>>>> On 2019-08-18 09:07, Mark Millard via freebsd-ports wrote:
>>>>>> I ran two separate devel/poudriere-devel amd64->aarch64
>>>>>> cross bui
On 2019-Aug-18, at 01:27, Mark Millard wrote:
> On 2019-Aug-18, at 01:03, Niclas Zeising wrote:
>
>> On 2019-08-18 09:48, Mark Millard wrote:
>>> On 2019-Aug-18, at 00:34, Niclas Zeising wrote:
>>>> On 2019-08-18 09:07, Mark Millard via freebsd-ports wrot
On 2019-Aug-18, at 01:03, Niclas Zeising wrote:
> On 2019-08-18 09:48, Mark Millard wrote:
>> On 2019-Aug-18, at 00:34, Niclas Zeising wrote:
>>> On 2019-08-18 09:07, Mark Millard via freebsd-ports wrote:
>>>> I ran two separate devel/poudriere-devel am
On 2019-Aug-18, at 00:34, Niclas Zeising wrote:
> On 2019-08-18 09:07, Mark Millard via freebsd-ports wrote:
>> I ran two separate devel/poudriere-devel amd64->aarch64
>> cross builds on the same system (head -r 351178 based)
>> with the same /usr/ports/ t
I ran two separate devel/poudriere-devel amd64->aarch64
cross builds on the same system (head -r 351178 based)
with the same /usr/ports/ tree (ports head -r509171),
building the same 97 ports each, mostly overlapping
in time, and one got:
gmake[2]: *** [Makefile:37: gen/apple_png.h] Error 2
[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,
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 in
>>> the 8.0 timeframe, but the lit build now
[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 to find a knob to disable
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 to find a knob to disable it. For now, the easy
> workaround is probably to
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]
Kevin Oberman rkoberman at gmail.com wrote on
Sun Jul 28 17:21:00 UTC 2019 :
> I used "portmaster -a". The problem is that all ports compiled with gcc had
> PORTREVISION bumped. Most do not have a run-time dependency on gcc.
Going in different direction than other responses
that I saw . . .
#
On 2019-Jul-24, at 03:02, Christoph Moench-Tegeder
wrote:
> ## Mark Millard via freebsd-ports (freebsd-ports@freebsd.org):
>
>> => imagesize-1.1.0.tar.gz doesn't seem to exist in /portdistfiles/.
>> => Attempting to fetch
>> https://files.pythonhosted.o
=> imagesize-1.1.0.tar.gz doesn't seem to exist in /portdistfiles/.
=> Attempting to fetch
https://files.pythonhosted.org/packages/source/i/imagesize/imagesize-1.1.0.tar.gz
fetch: transfer timed out
fetch: imagesize-1.1.0.tar.gz appears to be truncated: 0/1275201 bytes
=> Attempting to fetch
On 2019-Jul-23, at 15:09, Charlie Li wrote:
> David Wolfskill wrote:
>> On Tue, Jul 23, 2019 at 01:28:46PM -0700, Mark Millard via freebsd-ports
>> wrote:
>>> I'm unclear on why devel/llvm80 depends on graphics ports, but
>>> after 'svnlite update -r50724
I'm unclear on why devel/llvm80 depends on graphics ports, but
after 'svnlite update -r507241 /usr/ports' (not having updated
in some time), my poudriere bulk run reported:
[00:23:50] [26] [00:10:36] Finished graphics/py-imagesize@py27 |
py27-imagesize-1.1.0: Failed: fetch
[00:23:50] [26]
[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 matter what the system compiler
[I misinterpreted.]
On 2019-May-25, at 22:31, Mark Millard wrote:
> [I retried the build.]
>
> On 2019-May-25, at 19:49, Mark Millard wrote:
>
>> In over 16 minutes of CPU time the log file had 4 lines added:
>>
>> - zlib : yes (cached)
>> - bzip2
[I retried the build.]
On 2019-May-25, at 19:49, Mark Millard wrote:
> In over 16 minutes of CPU time the log file had 4 lines added:
>
>- zlib : yes (cached)
>- bzip2: yes (cached)
>- lzma : yes (cached)
>- zstd
[The FreeBSD is from a gcc 4.2.1 toolchain based build.]
My poudriere build of lang/ruby25 failed with:
--- compile.o ---
In file included from ./include/ruby.h:33,
from internal.h:15,
from compile.c:12:
In function 'iseq_build_kw.isra.76',
inlined from
In over 16 minutes of CPU time the log file had 4 lines added:
- zlib : yes (cached)
- bzip2: yes (cached)
- lzma : yes (cached)
- zstd : no (cached)
after:
- BOOST_COMP_GNUC >= 4.3.0 : yes
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++/libcxxrt . . .
>
> Yeah. This
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
[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 difference.]
>
> On 2019-May-23, at 14:17, Mark Millard wrote:
>
[I tried rebuilding things based on a full-bootstrap
build of lang/gcc8 instead. It made no difference.]
On 2019-May-23, at 14:17, Mark Millard wrote:
> [It looks like code generation missed a level of indirection
> to me.]
>
>> On 2019-May-23, at 13:46, Mark Millard wrote:
>>
>> [I should
[It looks like code generation missed a level of indirection
to me.]
> On 2019-May-23, at 13:46, Mark Millard wrote:
>
> [I should have listed uname -apKU output and such.]
>
> On 2019-May-23, at 13:21, Mark Millard wrote:
>
>> The poudriere bulk run that tried to build
[I should have listed uname -apKU output and such.]
On 2019-May-23, at 13:21, Mark Millard wrote:
> The poudriere bulk run that tried to build x11-toolkits/qt5-declarative
> got:
>
> --- qqmljsgrammar.cpp ---
> /usr/local/lib/qt5/bin/qlalr --no-debug --qt parser/qqmljs.g
> Segmentation fault
The poudriere bulk run that tried to build x11-toolkits/qt5-declarative
got:
--- qqmljsgrammar.cpp ---
/usr/local/lib/qt5/bin/qlalr --no-debug --qt parser/qqmljs.g
Segmentation fault (core dumped)
*** [qqmljsgrammar.cpp] Error code 139
make[3]: stopped in
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
[Just sending to toolchain and powerpc lists as well. Somehow I
missed listing them the first time I sent this out.]
On 2019-May-23, at 11:20, Mark Millard wrote:
> From a poudriere bulk build in a powerpc64 context (old PowerMac)
> that was built with and uses system clang 8 and base/binutils
>From a poudriere bulk build in a powerpc64 context (old PowerMac)
that was built with and uses system clang 8 and base/binutils
instead of the gcc 4.2.1 toolchain. I got:
[09:05:56] [04] [00:14:42] Saved graphics/mesa-dri | mesa-dri-18.3.2_2 wrkdir
to:
[I've tested the proposed Mk/Uses/qt-dist.mk fix.]
On 2019-May-21, at 17:15, Mark Millard wrote:
> On 2019-May-21, at 16:20, Mark Millard wrote:
>
>> I'm top posting because the problem originally reported seems to be
>> a later consequence of a much earlier problem. Looking in the logs
>>
On 2019-May-21, at 16:20, Mark Millard wrote:
> I'm top posting because the problem originally reported seems to be
> a later consequence of a much earlier problem. Looking in the logs
> showed lots of use of -I%%LOCALBASE%%/lib/gcc8/include/c++ and looking in:
>
>
I'm top posting because the problem originally reported seems to be
a later consequence of a much earlier problem. Looking in the logs
showed lots of use of -I%%LOCALBASE%%/lib/gcc8/include/c++ and looking in:
On 2019-May-21, at 06:56, James Shuriff wrote:
> What do you think of updating the bare metals to 9.1.0? I don’t know anything
> outside of U-Boot and the PSCI Monitor (rpi-firmware) that actually depends
> on those ports and I've tested them with my custom ports. The powerpc64-gcc
> patches
On 2019-May-19, at 07:40, James Shuriff wrote:
> I didn't/don't plan on touching binutils. Binutils is okay. I made new
> patches as well. What I'm really concerned with bringing up to date is
> aarch64-none-elf-gcc.
> The GNU toolchain is unfortunately required for building an Aarch64
This was in a poudriere bulk build on a head -r347549 based powerpc64
system with system clang 8 for cc and c++ and base/binutils
for the likes of ld. But the build of qt5-core uses g++8.
The log shows:
--- .obj/qatomic.o ---
g++8 -c -O2 -pipe -g -fstack-protector-strong
[It built with GNU ld (GNU Binutils) 2.32 as ld.]
On 2019-May-18, at 21:42, Mark Millard wrote:
> On 2019-May-18, at 21:11, Mark Millard wrote:
>
>> This was in a poudriere bulk build on a head -r347549 based powerpc64
>> system with system clang 8 for cc and c++ and base/binutils
>> for ld.
James Shuriff james at opentech.cc wrote on
Sat May 18 12:29:22 UTC 2019 :
> The powerpc64-gcc port and all the ports that use it as a master
> (aarch64-gcc, aarch64-none-elf-gcc, amd64-gcc, arm-none-eabi-gcc, i386-gcc,
> mips-gcc, mips64-gcc, and sparc64-gcc) are very old and use buggy
On 2019-May-18, at 21:11, Mark Millard wrote:
> This was in a poudriere bulk build on a head -r347549 based powerpc64
> system with system clang 8 for cc and c++ and base/binutils
> for ld. I was attempting a build with the -O1 changes disabled. (Note:
> the system is self hosting for buildworld
This was in a poudriere bulk build on a head -r347549 based powerpc64
system with system clang 8 for cc and c++ and base/binutils
for ld. I was attempting a build with the -O1 changes disabled. (Note:
the system is self hosting for buildworld buildkernel via the clang 8
and base/binutils
On 2019-Apr-7, at 22:16, Gerald Pfeifer wrote:
> Hmm, I received zero feedback on this proposal, when it appeared
> important for a number of users.
>
> What's your take, Andreas, Tijl (your patch essentially with a bit
> of an updated description), and toolchain?
>
> Gerald
>
> On Wed, 27
Eugene Grosbein eugen at grosbein.net wrote on
Sat Mar 23 23:16:40 UTC 2019 :
24.03.2019 1:38, Lucas Nali de Magalhães wrote:
> > I found a few bugs since I started rebuilding my system.
> > Most of them are related with the lack of handling of CPUTYPE=native
> > make.conf tunable.
>
> Use
Just FYI . . .
Adriaan de Groot adridg at freebsd.org wrote on
Mon Mar 11 14:22:10 UTC 2019 :
> On Monday, 11 March 2019 13:01:43 CET freebsd-ports-request at freebsd.org
> wrote:
> > ../qbearerengine_impl.h:48:1: error: expected class-name before '{' token
>
>
> I *imagine* (since I don't
My ports-mgmt/pouriere-devel based build attempt for building devel/llvm60
failed
with:
[00:00:53] [01] [00:00:00] Building devel/llvm60 | llvm60-6.0.1_6
[02:05:13] [01] [02:04:20] Saved devel/llvm60 | llvm60-6.0.1_6 wrkdir to:
My ports-mgmt/pouriere-devel based build attempt for building devel/llvm80
failed
with:
[00:01:11] [01] [00:00:00] Building devel/llvm80 | llvm80-8.0.0.r3
[04:30:47] [01] [04:29:36] Saved devel/llvm80 | llvm80-8.0.0.r3 wrkdir to:
ports-mgmt/poudriere-devel got:
[06:34:26] [02] [00:00:00] Building net/qt5-network | qt5-network-5.12.1
. . .
[06:47:03] [02] [00:12:37] Saved net/qt5-network | qt5-network-5.12.1 wrkdir
to:
/usr/local/poudriere/data/wrkdirs/FBSDpowerpc-default/default/qt5-network-5.12.1.tbz
[06:47:03] [02]
The below is from a ports-mgmt/poudriere-devel run under FreeBSD head
-r344825 on an old PowerMac G5 (2 sockets, 2 cores each, powerpc64).
The /usr/ports is from head -r494751 . buildworld buildkernel
was via devel/powerpc64-xtoolchain-gcc materials and system-clang
(8.0.0) was built (and
The below is from a ports-mgmt/poudriere-devel run under FreeBSD head
-r344825 on an old PowerMac G5 (2 sockets, 2 cores each, powerpc64).
The /usr/ports is from head -r494751 . buildworld buildkernel
was via devel/powerpc64-xtoolchain-gcc materials and system-clang
(8.0.0) was built (and
On 2019-Feb-10, at 07:14, Steve Kargl
wrote:
> On Sun, Feb 10, 2019 at 11:34:28AM -0200, Lucas Nali de Magalhães wrote:
>>>
>>> My lumina builds indirectly build qt5-qui and have been having
Dumb typo on my part: should have been a qt5-gui reference.
>>> no problems (targeting amd64,
101 - 200 of 328 matches
Mail list logo
