Am 19.04.25 um 16:02 schrieb Mark Johnston:
On Sat, Apr 19, 2025 at 06:06:59AM -0700, David Wolfskill wrote:
Running:
FreeBSD g1-118.catwhisker.org 15.0-CURRENT FreeBSD 15.0-CURRENT #445
main-n276537-7121e9414f29: Fri Apr 18 12:36:30 UTC 2025
r...@g1-120.catwhisker.org:/common/S4/obj/usr/s
On Sat, Apr 19, 2025 at 06:06:59AM -0700, David Wolfskill wrote:
> Running:
> FreeBSD g1-118.catwhisker.org 15.0-CURRENT FreeBSD 15.0-CURRENT #445
> main-n276537-7121e9414f29: Fri Apr 18 12:36:30 UTC 2025
> r...@g1-120.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64
>
> af
commit a3a88ed appears to have removed the function(s) needed by drm
kmod to build and run :-(
Michael
On 4/19/25 09:06, David Wolfskill wrote:
Running:
FreeBSD g1-118.catwhisker.org 15.0-CURRENT FreeBSD 15.0-CURRENT #445
main-n276537-7121e9414f29: Fri Apr 18 12:36:30 UTC 2025
r.
gt; > > This is in meta-mode, on a 32x2 Epyc running "make -j 112 buildworld".
> >
> > I'm just guessing here - but ISTR that with large -j that sometimes a
> build
> > failure can occur. I've just had one where I forgot where I was and ran
&
On Mon, Oct 21, 2024 at 08:02:50PM +0100, void wrote:
> On Sun, Oct 20, 2024 at 05:14:29AM -0700, David Wolfskill wrote:
>
> > This is in meta-mode, on a 32x2 Epyc running "make -j 112 buildworld".
>
> I'm just guessing here - but ISTR that with large -j tha
On Sun, Oct 20, 2024 at 05:14:29AM -0700, David Wolfskill wrote:
This is in meta-mode, on a 32x2 Epyc running "make -j 112 buildworld".
I'm just guessing here - but ISTR that with large -j that sometimes a build
failure can occur. I've just had one where I forgot where
Hello,
Same here with meta-mode on a i7 laptop.
David Wolfskill escreveu (domingo, 20/10/2024 à(s)
13:15):
> Running:
> FreeBSD freebeast.catwhisker.org 15.0-CURRENT FreeBSD 15.0-CURRENT #5
> main-n273063-4ad443a106d3: Sat Oct 19 10:38:11 UTC 2024
> r...@freebeast.catwhisker.org:/common/S4/obj/
Running:
FreeBSD freebeast.catwhisker.org 15.0-CURRENT FreeBSD 15.0-CURRENT #5
main-n273063-4ad443a106d3: Sat Oct 19 10:38:11 UTC 2024
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC
amd64 1500025 1500025
after updating sources to main-n273073-bd66c1b43e33:
...
On 9/29/24 16:24, void wrote:
On Sun, Sep 29, 2024 at 02:13:01PM +, Gary Jennejohn wrote:
I personally have been using a customized kernel configuration file for
25 years or more and I have no intention of changing it.
Just because INET6 shows up in all the boilerplate config files doesn't
On 9/29/24 16:02, Rodney W. Grimes wrote:
On Sun, Sep 29, 2024 at 02:13:01PM +, Gary Jennejohn wrote:
...
NOT all things need to be network connected!
At great risk of tossing yet another coat of paint onto the bikeshed
I must agree that a machine with nothing other than serial conn
> On Sun, Sep 29, 2024 at 02:13:01PM +, Gary Jennejohn wrote:
>
> >I personally have been using a customized kernel configuration file for
> >25 years or more and I have no intention of changing it.
> >
> >Just because INET6 shows up in all the boilerplate config files doesn't
> >change the fa
On Sun, Sep 29, 2024 at 02:13:01PM +, Gary Jennejohn wrote:
I personally have been using a customized kernel configuration file for
25 years or more and I have no intention of changing it.
Just because INET6 shows up in all the boilerplate config files doesn't
change the fact that INET6 is
On Sun, 29 Sep 2024 11:53:10 +0200
Kristof Provost wrote:
> > On 29 Sep 2024, at 04:46, Zhenlei Huang wrote:
> >
> > ?
> >
> >> On Sep 27, 2024, at 6:07 PM, Gary Jennejohn wrote:
> >>
> >>> On Thu, 26 Sep 2024 14:58:40 -0400
> >>> Ian FREISLICH wrote:
> >>>
> >>> Lately there have been a coupl
> On 29 Sep 2024, at 04:46, Zhenlei Huang wrote:
>
>
>
>> On Sep 27, 2024, at 6:07 PM, Gary Jennejohn wrote:
>>
>>> On Thu, 26 Sep 2024 14:58:40 -0400
>>> Ian FREISLICH wrote:
>>>
>>> Lately there have been a couple of commits that fail to build because v6
>>> being compiled in despite
> On Sep 27, 2024, at 6:07 PM, Gary Jennejohn wrote:
>
> On Thu, 26 Sep 2024 14:58:40 -0400
> Ian FREISLICH wrote:
>
>> Lately there have been a couple of commits that fail to build because v6
>> being compiled in despite INET6 being undefined. I think the latest is
>> 905db4aa887758650977
On Thu, 26 Sep 2024 14:58:40 -0400
Ian FREISLICH wrote:
> Lately there have been a couple of commits that fail to build because v6
> being compiled in despite INET6 being undefined. I think the latest is
> 905db4aa88775865097714c170f4503da385747c.
>
> /usr/src/sys/netpfil/pf/pf.c:8762:38: error
Lately there have been a couple of commits that fail to build
because v6 being compiled in despite INET6 being undefined. I think
the latest is 905db4aa88775865097714c170f4503da385747c.
/usr/src/sys/netpfil/pf/pf.c:8762:38: error: no member named 'icmp6'
in 'union p
On 07/30/2024 9:25 am, Larry Rosenman wrote:
On 07/30/2024 9:22 am, Ed Maste wrote:
On Mon, 29 Jul 2024 at 19:54, Larry Rosenman wrote:
I'm getting the following on an up2date checkout:
Building /usr/obj/usr/src/amd64.amd64/usr.bin/clang/clang/clang.full
ld: warning:
/usr/obj/usr/src/amd64.a
On 07/30/2024 9:22 am, Ed Maste wrote:
On Mon, 29 Jul 2024 at 19:54, Larry Rosenman wrote:
I'm getting the following on an up2date checkout:
Building /usr/obj/usr/src/amd64.amd64/usr.bin/clang/clang/clang.full
ld: warning: /usr/obj/usr/src/amd64.amd64/lib/clang/libllvm/libllvm.a:
archive membe
On Mon, 29 Jul 2024 at 19:54, Larry Rosenman wrote:
>
> I'm getting the following on an up2date checkout:
> Building /usr/obj/usr/src/amd64.amd64/usr.bin/clang/clang/clang.full
> ld: warning: /usr/obj/usr/src/amd64.amd64/lib/clang/libllvm/libllvm.a:
> archive member 'FaultMaps.o' is neither ET_REL
I'm getting the following on an up2date checkout:
Building /usr/obj/usr/src/amd64.amd64/usr.bin/clang/clang/clang.full
ld: warning: /usr/obj/usr/src/amd64.amd64/lib/clang/libllvm/libllvm.a:
archive member 'FaultMaps.o' is neither ET_REL nor LLVM bitcode
ld: warning: /usr/obj/usr/src/amd64.amd64/l
Scanning the build typescript, I find:
...
Building /common/S4/obj/usr/src/amd64.amd64/usr.bin/w/uptime.1.gz
ld: error: undefined symbol: libzfs_core_init
>>> referenced by zdb.c:9207 (/usr/src/sys/contrib/openzfs/cmd/zdb/zdb.c:9207)
>>> zdb.o:(main)
Building /common/S4/obj/usr/src/a
ub.com/amsynth/amsynth/commit/6fb79100a6254220e5adc69a1428572539ecc377
>
> I'm using patch globally that unbreak main and rest of supported releases
> don't complaint about it.
>
> Thanks!
>
> Dimitry Andric escreveu (terça, 30/04/2024 à(s) 18:45):
> On 30 Apr 2024, at 14:26, Nu
out it.
Thanks!
Dimitry Andric escreveu (terça, 30/04/2024 à(s) 18:45):
> On 30 Apr 2024, at 14:26, Nuno Teixeira wrote:
> >
> > I'm lost on build failure of audio/amsynth (updated to version 1.13.3)
> on recent main.
> > Thre strange thing is if I use llvm from ports,
On 30 Apr 2024, at 14:26, Nuno Teixeira wrote:
>
> I'm lost on build failure of audio/amsynth (updated to version 1.13.3) on
> recent main.
> Thre strange thing is if I use llvm from ports, USES+=llvm, it fails with
> same error so I suspect that something related to ma
Hello all,
I'm lost on build failure of audio/amsynth (updated to version 1.13.3) on
recent main.
Thre strange thing is if I use llvm from ports, USES+=llvm, it fails with
same error so I suspect that something related to main.
Any help is welcome and I didn't openned an upstream PR ye
> > > This could be a dependency issue; would you check if removing the
> > > following $OBJTOP subdirs addresses the issue:
> > >
> > > secure/lib/libcrypto
> > > secure/lib/libssl
> > > obj-lib32/secure/lib/libcrypto
> > > obj-lib32/secure/lib/libssl
> > >
> The build was successful; after the re
On Sat, Jun 24, 2023 at 09:09:00AM -0700, David Wolfskill wrote:
> On Sat, Jun 24, 2023 at 10:39:57AM -0400, Ed Maste wrote:
> > ...
> > > : "OPENSSL_API_COMPAT expresses an impossible API compatibility level"
> > > # error "OPENSSL_API_COMPAT expresses an impossible API compatibility
> > > level
On Sat, Jun 24, 2023 at 10:39:57AM -0400, Ed Maste wrote:
> ...
> > : "OPENSSL_API_COMPAT expresses an impossible API compatibility level"
> > # error "OPENSSL_API_COMPAT expresses an impossible API compatibility
> > level"
> >^
>
> This could be a dependency issue; would you check if removi
On Sat, 24 Jun 2023 at 07:11, David Wolfskill wrote:
>
> Running:
> FreeBSD freebeast.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #405
> main-n263767-764464af4968: Fri Jun 23 11:42:14 UTC 2023
> r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC
> amd64 140009
Running:
FreeBSD freebeast.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #405
main-n263767-764464af4968: Fri Jun 23 11:42:14 UTC 2023
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC
amd64 1400091 1400091
after updating sources to main-n263782-59833b089e78, th
On Wed, May 24, 2023 at 01:39:26PM +0200, Dimitry Andric wrote:
> On 24 May 2023, at 13:25, David Wolfskill wrote:
> >
> > This is from an in-place source update from main-n263073-634a770a5e16 to
> > main-n263112-ad513b4dba3e:
> >
> > ...
> > Building /common/S4/obj/usr/src/amd64.amd64/lib/libc/
On 24 May 2023, at 13:25, David Wolfskill wrote:
>
> This is from an in-place source update from main-n263073-634a770a5e16 to
> main-n263112-ad513b4dba3e:
>
> ...
> Building /common/S4/obj/usr/src/amd64.amd64/lib/libc/tests/stdio/scanf_test
> Building /common/S4/obj/usr/src/amd64.amd64/usr.bin/n
David Wolfskill wrote:
> This is from an in-place source update from main-n263073-634a770a5e16 to
> main-n263112-ad513b4dba3e:
>
> ...
> Building /common/S4/obj/usr/src/amd64.amd64/lib/libc/tests/stdio/scanf_test
> Building /common/S4/obj/usr/src/amd64.amd64/usr.bin/ncurses/dump_entry.o
> Building
This is from an in-place source update from main-n263073-634a770a5e16 to
main-n263112-ad513b4dba3e:
...
Building /common/S4/obj/usr/src/amd64.amd64/lib/libc/tests/stdio/scanf_test
Building /common/S4/obj/usr/src/amd64.amd64/usr.bin/ncurses/dump_entry.o
Building
/common/S4/obj/usr/src/amd64.amd64/
Quoting Ryan Moeller (from Fri, 3 Feb 2023
10:48:35 -0500):
The build still fails on -current as of end of Jan with "too few
argument to function call, expected 4, have 3" for zfs_iter_filesystems.
Is a patch for openzfs in -current missing? I haven't seen a commit to
-current in openzfs in
Quoting Ryan Moeller (from Thu, 2 Feb 2023
10:43:53 -0500):
I've updated the py-libzfs port to fix the build.
The build still fails on -current as of end of Jan with "too few
argument to function call, expected 4, have 3" for zfs_iter_filesystems.
Is a patch for openzfs in -current miss
Thanks! But for the record, what was the actual required change?
Could you like to the PR?
On Thu, Feb 2, 2023 at 8:44 AM Ryan Moeller wrote:
>
> I've updated the py-libzfs port to fix the build.
>
> --
> Ryan Moeller
> iXsystems, Inc.
> OS Developer
> Email: r...@ixsystems.com
Quoting Alan Somers (from Thu, 2 Feb 2023
06:58:35 -0700):
Unfortunately libzfs doesn't have a stable API, so this kind of
breakage is to be expected. libzfs_core does, but libzfs_core is
incomplete. You should report this problem upstream at
https://github.com/truenas/py-libzfs .
I did a
Unfortunately libzfs doesn't have a stable API, so this kind of
breakage is to be expected. libzfs_core does, but libzfs_core is
incomplete. You should report this problem upstream at
https://github.com/truenas/py-libzfs .
On Thu, Feb 2, 2023 at 2:37 AM Alexander Leidinger
wrote:
>
> Hi,
>
> th
Hi,
the build of py-libzfs fails on -current due to a missing
zpool_search_import(), and as such iocage can not be build (and the
old iocage segfaults, so the ABI seems to have changed too). The
symbol is available in libzutil, but I can not find
zpool_search_import() in /usr/include.
A
On Thu, 12 Jan 2023 10:37:34 -0700
Warner Losh wrote:
> On Thu, Jan 12, 2023 at 4:44 AM David Wolfskill
> wrote:
>
> > > I had this problem also. After deleting obj/usr the buildworld
> succeeded.
> > >
> >
>
> > >
> >
> > Empirically:
> > rm -fr /usr/obj/usr/src/amd64.amd64/u
On Thu, Jan 12, 2023 at 4:44 AM David Wolfskill
wrote:
> On Wed, Jan 11, 2023 at 07:12:46AM -0700, Warner Losh wrote:
> > looks like we may need another 'unclean' workaround for this?
> >
> > Warner
> >
> > On Wed, Jan 11, 2023 at 6:32 AM Gary Jennejohn wrote:
> > ...
> > > I had this problem al
On Fri, 13 Jan 2023 01:31:59 +0900
Tomoaki AOKI wrote:
> On Thu, 12 Jan 2023 14:41:19 +
> Gary Jennejohn wrote:
>
[SNIP]
> >
> > I installed the new world on my tower this morning. Now I see a new
> > problem.
> >
> > I don't know whether this new problem is related to the new tzcode, but
>
On Thu, 12 Jan 2023 14:41:19 +
Gary Jennejohn wrote:
> On Thu, 12 Jan 2023 03:44:03 -0800
> David Wolfskill wrote:
>
> > On Wed, Jan 11, 2023 at 07:12:46AM -0700, Warner Losh wrote:
> > > looks like we may need another 'unclean' workaround for this?
> > >
> > > Warner
> > >
> > > On Wed, Ja
On Thu, 12 Jan 2023 03:44:03 -0800
David Wolfskill wrote:
> On Wed, Jan 11, 2023 at 07:12:46AM -0700, Warner Losh wrote:
> > looks like we may need another 'unclean' workaround for this?
> >
> > Warner
> >
> > On Wed, Jan 11, 2023 at 6:32 AM Gary Jennejohn wrote:
> > ...
> > > I had this problem
On Wed, Jan 11, 2023 at 07:12:46AM -0700, Warner Losh wrote:
> looks like we may need another 'unclean' workaround for this?
>
> Warner
>
> On Wed, Jan 11, 2023 at 6:32 AM Gary Jennejohn wrote:
> ...
> > I had this problem also. After deleting obj/usr the buildworld succeeded.
> >
>
Empi
looks like we may need another 'unclean' workaround for this?
Warner
On Wed, Jan 11, 2023 at 6:32 AM Gary Jennejohn wrote:
> On Wed, 11 Jan 2023 04:05:43 -0800
> David Wolfskill wrote:
>
> > Running:
> > FreeBSD freebeast.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #275
> main-n259988-48d
On Wed, 11 Jan 2023 04:05:43 -0800
David Wolfskill wrote:
> Running:
> FreeBSD freebeast.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #275
> main-n259988-48dc9150ac36: Tue Jan 10 12:20:47 UTC 2023
> r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC
> amd64
>
Running:
FreeBSD freebeast.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #275
main-n259988-48dc9150ac36: Tue Jan 10 12:20:47 UTC 2023
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC
amd64
and performing an in-place source update to main-n260011-40bb52c89b87
u
Hello,
On 21.12.22 01:24, Mark Millard wrote:
Alain Zscheile wrote on
Date: Tue, 20 Dec 2022 23:12:40 UTC :
I encountered a build failure while trying to build fbsd'
src.git commit ae521fda895ff0b5076904f08ec92e3c60d53701
That commit is from main:
• git: ae521fda895f - main - st
Alain Zscheile wrote on
Date: Tue, 20 Dec 2022 23:12:40 UTC :
> I encountered a build failure while trying to build fbsd'
> src.git commit ae521fda895ff0b5076904f08ec92e3c60d53701
That commit is from main:
• git: ae521fda895f - main - stress2: Added link to problem found Peter H
Hello,
I encountered a build failure while trying to build fbsd'
src.git commit ae521fda895ff0b5076904f08ec92e3c60d53701
with `make -j4 buildworld` on an FreeBSD 13.1 system.
--- all_subdir_lib/libclang_rt ---
ld: error: /usr/obj/usr/src/amd64.amd64/tmp/usr/lib/libc++.so:2:
cannot find
--- dpaa2_mc_acpi.o ---
/usr/main-src/sys/dev/dpaa2/dpaa2_mc_acpi.c:186:2: error: implicit declaration
of function 'AcpiUtTrace' is invalid in C99
[-Werror,-Wimplicit-function-declaration]
ACPI_FUNCTION_TRACE((char *)(uintptr_t) __func__);
^
/usr/main-src/sys/contrib/dev/acpica/in
make buildworld -DWITH_UBSAN -DWITH_ASAN is failing for me with the error:
building shared library libc.so.7
ld: error: cannot open
/usr/home/ctuffli/dev/freebsd/obj/usr/home/ctuffli/dev/freebsd/src.git/amd64.amd64/tmp/usr/lib/clang/14.0.5/lib/freebsd/libclang_rt.asan_static-x86_64.a:
No such file
On Fri, 17 Dec 2021 09:44:20 -0800
Chuck Tuffli wrote:
> When building current from git, I keep hitting the error below. This
> is with meta-mode, but I've also tried deleting the object directory.
> The system also has a couple of tweaks to src-env.conf that were an
> attempt to avoid building a
When building current from git, I keep hitting the error below. This
is with meta-mode, but I've also tried deleting the object directory.
The system also has a couple of tweaks to src-env.conf that were an
attempt to avoid building any (most?) of clang. Relevant system
information:
$ uname -mrsv
On Tue, Oct 20, 2020 at 07:15:16AM +, you (marco) sent the following to
[freebsd-current] :
> >
>
> I checked out 05b104834ae7 (r366780) from
> https://cgit-beta.freebsd.org/src.git and ran a 'make -j4 builworld and make
> -j4 buildkernel'
> for GENERIC-NODEBUG which also failed (buildworld
On Sat, Oct 03, 2020 at 10:36:30AM +0200, you (Emmanuel Vadot) sent the
following to [freebsd-current] :
> On Fri, 2 Oct 2020 19:53:44 -0500
> Patrick McMunn wrote:
>
> > I update the sources today and ran "make -j24 buildworld buildkernel
> > KERNCONF=GENERIC-NODEBUG", and the build failed. I m
On Fri, 2 Oct 2020 19:53:44 -0500
Patrick McMunn wrote:
> I update the sources today and ran "make -j24 buildworld buildkernel
> KERNCONF=GENERIC-NODEBUG", and the build failed. I made sure to "make
> clean" and "make cleanworld" and try again, and I got the same result.
>
> --
> Patrick McMunn
I update the sources today and ran "make -j24 buildworld buildkernel
KERNCONF=GENERIC-NODEBUG", and the build failed. I made sure to "make
clean" and "make cleanworld" and try again, and I got the same result.
--
Patrick McMunn
- Learn more about the Catholic Faith: http://www.catholic.com/
- Pr
Le dim. 20 sept. 2020 à 16:59, Mark Murray a écrit :
>
> Hi *
>
> I've been getting these build failures for a while (weeks/months). The
> machine is a MacchiatoBin DoubleShot (arm64, Quad core). with SATA disks and
> zfs filesystem. If I empty out /usr/obj, then the build works, but takes a
>
On 9/20/20 10:58 AM, Mark Murray wrote:
Hi *
I've been getting these build failures for a while (weeks/months). The machine is a MacchiatoBin
DoubleShot (arm64, Quad core). with SATA disks and zfs filesystem. If I empty out /usr/obj, then
the build works, but takes a few hours. If I do a no-cl
Hi *
I've been getting these build failures for a while (weeks/months). The machine
is a MacchiatoBin DoubleShot (arm64, Quad core). with SATA disks and zfs
filesystem. If I empty out /usr/obj, then the build works, but takes a few
hours. If I do a no-clean build with /obj/obj populated with he
When cross-compiling for i386 on amd64 (which has 2 by 4 cores), I get
the error below after a previously successful build.
Running the build again (a 3rd time) completes successfully :-(
This is the output from
cd /usr/src/release; ./release.sh -c release-i386.conf
[ .. ]
===> usr.bi
On Fri, Jan 04, 2019 at 07:56:42AM +0100, Michal Meloun wrote:
> On 29.12.2018 18:47, Dennis Clarke wrote:
> > On 12/28/18 9:56 PM, Mark Millard via freebsd-arm wrote:
> >>
> >> On 2018-Dec-28, at 12:12, Mark Millard wrote:
> >>
> >>> On 2018-Dec-28, at 05:13, Michal Meloun
> >>> wrote:
> >>>
> >
On 2019-Jan-3, at 22:56, Michal Meloun wrote:
> On 29.12.2018 18:47, Dennis Clarke wrote:
>> On 12/28/18 9:56 PM, Mark Millard via freebsd-arm wrote:
>>>
>>> On 2018-Dec-28, at 12:12, Mark Millard wrote:
>>>
On 2018-Dec-28, at 05:13, Michal Meloun
wrote:
> Mark,
> t
On 29.12.2018 18:47, Dennis Clarke wrote:
> On 12/28/18 9:56 PM, Mark Millard via freebsd-arm wrote:
>>
>> On 2018-Dec-28, at 12:12, Mark Millard wrote:
>>
>>> On 2018-Dec-28, at 05:13, Michal Meloun
>>> wrote:
>>>
Mark,
this is known problem with qemu-user-static.
Emulation of eve
[I listed my /usr/src svn veriosn information instead of /usr/ports .
Correcting. . .]
On 2018-Dec-31, at 12:05, Mark Millard wrote:
> On 2018-Dec-31, at 10:16, Jonathan Chen wrote:
>
>> On Mon, 31 Dec 2018 at 21:05, Mark Millard wrote:
>> [...]
>>> But if you have a form of hang-up that show
On 2018-Dec-31, at 10:16, Jonathan Chen wrote:
> On Mon, 31 Dec 2018 at 21:05, Mark Millard wrote:
> [...]
>> But if you have a form of hang-up that shows no sign of being tied
>> to kevent or hangs-up only sometimes, I'd be surprised if the __packed
>> change(s) would fix the issue.
>
> With t
On Mon, 31 Dec 2018 at 21:05, Mark Millard wrote:
[...]
> But if you have a form of hang-up that shows no sign of being tied
> to kevent or hangs-up only sometimes, I'd be surprised if the __packed
> change(s) would fix the issue.
With the __packed-modified qemu-user-static, the amd64->armv7
cros
On Mon, 31 Dec 2018 at 14:34, Mark Millard via freebsd-ports
wrote:
>
> [Removing __packed did make the size and offsets match armv7
> and the build worked based on the reconstructed qemu-arm-static.]
Thanks for the analysis Mark! I've been suffering quite a few hangups
with my ports crossbuilds
On 2018-Dec-30, at 21:01, Jonathan Chen wrote:
> On Mon, 31 Dec 2018 at 14:34, Mark Millard via freebsd-ports
> wrote:
>>
>> [Removing __packed did make the size and offsets match armv7
>> and the build worked based on the reconstructed qemu-arm-static.]
>
> Thanks for the analysis Mark! I've
[Removing __packed did make the size and offsets match armv7
and the build worked based on the reconstructed qemu-arm-static.]
On 2018-Dec-30, at 16:38, Mark Millard wrote:
> On 2018-Dec-28, at 12:12, Mark Millard wrote:
>
>> On 2018-Dec-28, at 05:13, Michal Meloun wrote:
>>
>>> Mark,
>>> th
On 2018-Dec-28, at 12:12, Mark Millard wrote:
> On 2018-Dec-28, at 05:13, Michal Meloun wrote:
>
>> Mark,
>> this is known problem with qemu-user-static.
>> Emulation of every single interruptible syscall is broken by design (it
>> have signal related races). Theses races cannot be solved wi
On 2018-Dec-28, at 12:12, Mark Millard wrote:
> On 2018-Dec-28, at 05:13, Michal Meloun wrote:
>
>> Mark,
>> this is known problem with qemu-user-static.
>> Emulation of every single interruptible syscall is broken by design (it
>> have signal related races). Theses races cannot be solved wit
[Using ktrace/kdump shows an apperent oddity in the kevent use that
hang-up in cmake, not that I know it causes the hang-up.]
On 2018-Dec-28, at 00:16, Mark Millard wrote:
> [The historical notes are removed and replaced by partial trace
> information from example hang-ups, not that I've figured
On 2018-Dec-28, at 05:13, Michal Meloun wrote:
> Mark,
> this is known problem with qemu-user-static.
> Emulation of every single interruptible syscall is broken by design (it
> have signal related races). Theses races cannot be solved without major
> rewrite of syscall emulation code.
> Unfor
On 24.12.2018 8:28, Mark Millard wrote:
> [I built a FreeBSD head -r340288 context and tried ports head
> -r484783 and the problem repeated.]
>
> On 2018-Dec-22, at 12:55, Mark Millard wrote:
>
>> [I found my E-mail records reporting successful builds using
>> qemu-user-static from ports head
On 24.12.2018 8:28, Mark Millard wrote:
> [I built a FreeBSD head -r340288 context and tried ports head
> -r484783 and the problem repeated.]
>
> On 2018-Dec-22, at 12:55, Mark Millard wrote:
>
>> [I found my E-mail records reporting successful builds using
>> qemu-user-static from ports head
[The historical notes are removed and replaced by partial trace
information from example hang-ups, not that I've figured out
what contributes yet.]
I ran into the following while trying to get evidence
about the hang-up for an amd64->armv7 cross-build of
multimedia/gstreamer1-qt@qt5 .
The followi
[A native poudreire-devel based build of
multimedia/gstreamer1-qt@qt5 did not hang-up
and worked fine. Official package build history
also provides some evidence.]
On 2018-Dec-22, at 12:55, Mark Millard wrote:
> [I found my E-mail records reporting successful builds using
> qemu-user-static from
[I built a FreeBSD head -r340288 context and tried ports head
-r484783 and the problem repeated.]
On 2018-Dec-22, at 12:55, Mark Millard wrote:
> [I found my E-mail records reporting successful builds using
> qemu-user-static from ports head -r484783 under FreeBSD
> head -r340287.]
>
> On 2018-
[I found my E-mail records reporting successful builds using
qemu-user-static from ports head -r484783 under FreeBSD
head -r340287.]
On 2018-Dec-22, at 00:10, Mark Millard wrote:
> [I messed up the freebsd-emulation email address the first time I sent
> this. I also forgot to indicate the qemu-u
[I messed up the freebsd-emulation email address the first time I sent
this. I also forgot to indicate the qemu-user-static vintage relationship.]
I had been reporting intermittent hang-ups for my amd64->{aarch64,armv7} port
cross
builds in another message sequence. But it turns out that one thin
I had been reporting intermittent hang-ups for my amd64->{aarch64,armv7} port
cross
builds in another message sequence. But it turns out that one thing I ran into
has hung-up every time, the same way, for amd64->armv7 cross builds:
multimedia/gstreamer1-qt@qt5 . So I extract the material here into
Confirmed to be fixed by SVN r340134 - thanks!
On 11/4/18 1:50 PM, Michael Butler wrote:
> ===> libexec/dma/dma-mbox-create (all)
> Building
> /usr/obj/usr/src/amd64.amd64/libexec/dma/dma-mbox-create/dma-mbox-create.o
> In file included from /usr/src/contrib/dma/dma-mbox-create.c:51:
> /usr/obj/us
On Sun, Nov 04, 2018 at 01:50:31PM -0500, Michael Butler wrote:
> ===> libexec/dma/dma-mbox-create (all)
> Building
> /usr/obj/usr/src/amd64.amd64/libexec/dma/dma-mbox-create/dma-mbox-create.o
> In file included from /usr/src/contrib/dma/dma-mbox-create.c:51:
> /usr/obj/usr/src/amd64.amd64/tmp/usr/
===> libexec/dma/dma-mbox-create (all)
Building
/usr/obj/usr/src/amd64.amd64/libexec/dma/dma-mbox-create/dma-mbox-create.o
In file included from /usr/src/contrib/dma/dma-mbox-create.c:51:
/usr/obj/usr/src/amd64.amd64/tmp/usr/include/capsicum_helpers.h:161:1:
error: all paths through this function w
On 8/14/18 1:35 AM, Matthew Macy wrote:
> On Mon, Aug 13, 2018 at 5:33 PM Rick Macklem wrote:
>
>> Rodney W. Grimes wrote:
On Sun, 12 Aug 2018 14:39-0700, Matthew Macy wrote:
> Sorry guys, last time I touched ZFS I tried to push to make it an
>> option to
> statically link and w
On Mon, Aug 13, 2018 at 09:53:22PM -0400, Michael Butler wrote:
> non-SMP builds apparently don't define some required structures ..
Thanks, this should be fixed by r337751.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/l
[ Charset ISO-8859-1 unsupported, converting... ]
> Rodney W. Grimes wrote:
> >> On Sun, 12 Aug 2018 14:39-0700, Matthew Macy wrote:
> >>
> >> > Sorry guys, last time I touched ZFS I tried to push to make it an option
> >> > to
> >> > statically link and was actually told that it wasn't something
non-SMP builds apparently don't define some required structures ..
--- kernel ---
linking kernel
ld: error: undefined symbol: cpu_info
>>> referenced by ucode.c
>>> ucode.o:(ucode_load_ap)
ld: error: undefined symbol: cpu_apic_ids
>>> referenced by ucode.c
>>> ucode.o:(
On Mon, Aug 13, 2018 at 5:33 PM Rick Macklem wrote:
> Rodney W. Grimes wrote:
> >> On Sun, 12 Aug 2018 14:39-0700, Matthew Macy wrote:
> >>
> >> > Sorry guys, last time I touched ZFS I tried to push to make it an
> option to
> >> > statically link and was actually told that it wasn't something an
Rodney W. Grimes wrote:
>> On Sun, 12 Aug 2018 14:39-0700, Matthew Macy wrote:
>>
>> > Sorry guys, last time I touched ZFS I tried to push to make it an option to
>> > statically link and was actually told that it wasn't something anyone else
>> > wanted. The issue comes from ZFS not being in NOTES
Rodney W. Grimes wrote:
On Sun, 12 Aug 2018 14:39-0700, Matthew Macy wrote:
Sorry guys, last time I touched ZFS I tried to push to make it an option to
statically link and was actually told that it wasn't something anyone else
wanted. The issue comes from ZFS not being in NOTES and thus not in
> On Sun, 12 Aug 2018 14:39-0700, Matthew Macy wrote:
>
> > Sorry guys, last time I touched ZFS I tried to push to make it an option to
> > statically link and was actually told that it wasn't something anyone else
> > wanted. The issue comes from ZFS not being in NOTES and thus not in LINT.
>
>
On Sun, 12 Aug 2018 14:39-0700, Matthew Macy wrote:
> Sorry guys, last time I touched ZFS I tried to push to make it an option to
> statically link and was actually told that it wasn't something anyone else
> wanted. The issue comes from ZFS not being in NOTES and thus not in LINT.
If consensus i
On Sun, Aug 12, 2018, 4:27 PM Matthew Macy wrote:
>
>
> On Sun, Aug 12, 2018 at 3:25 PM Warner Losh wrote:
>
>>
>>
>> On Sun, Aug 12, 2018, 3:40 PM Matthew Macy wrote:
>>
>>> Sorry guys, last time I touched ZFS I tried to push to make it an option
>>> to
>>> statically link and was actually tol
On Sun, Aug 12, 2018 at 3:25 PM Warner Losh wrote:
>
>
> On Sun, Aug 12, 2018, 3:40 PM Matthew Macy wrote:
>
>> Sorry guys, last time I touched ZFS I tried to push to make it an option
>> to
>> statically link and was actually told that it wasn't something anyone else
>> wanted. The issue comes
1 - 100 of 422 matches
Mail list logo
