Re: Segfault in _Unwind_* code called from pthread_exit
On Sun, 5 Nov 2017, Andreas Tobler wrote: > Pushed on all active branches, 8/7/6. Saw that, thank you. Very well done, Andreas! I should have gcc8-devel updated in the next 24 hours, gcc7-devel and gcc6-devel over the week as new snapshots are released. > If you could do the gcc* branches, yes please. Once the respective -devel ports are updated, I'll take care of the corresponding stable ports. > I got one request to have the patch also in gcc5 Let's see. First I want to address the five newer ports, then possibly this one (though gcc5 is hardly used). Gerald ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Booting native 4K SSD disk from FreeBSD ?
On Thu, 02 Nov 2017 13:08:49 +0200, Toomas Soome wrote: With r325310, the UEFI boot with CURRENT should be ok with >512B sectors. The BIOS part is still work in the process. I can confirm that I'm now able to boot my Macbook Pro with 4K SSD. On 4 Oct 2017, at 19:32, Allan Jude wrote: On 2017-10-04 05:27, Thomas Mueller wrote: from Allan Jude: Anyone has any recommendations or experience about how to use native 4K disks with FreeBSD? --HPS It is not possible in legacy/BIOS mode, because the BIOS calls do not let you specify a sector size. However, you SHOULD be able to boot from the 4k device using UEFI. I am trying to debug a problem I am having with this on my new Mac, which has a 4k NVMe disk. I've been trying to figure how to boot a FreeBSD system with UEFI as opposed to BIOS-style. I read the documentation, but want to boot a partition that might not be the first BSD partition on the hard disk. For instance, some UFS partitions might have a NetBSD installation, a different FreeBSD installation, or no OS installation. I read the man page (uefi) and looked at the files in /boot; have an EFI partition set up with more than enough space. I would also want to be able to boot other UEFI-capable OSes including Linux, NetBSD (if that works), and Haiku when and if possible. Tom ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" In this case, You likely want to install a tool like rEFInd, which will draw a menu of all of the installed OSes and let you pick. I use this in two of my laptops, one dual boots freebsd and windows, and the other OS X and FreeBSD on my macbook pro ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Segfault in _Unwind_* code called from pthread_exit
On 05.11.17 21:31, Gerald Pfeifer wrote: On Sun, 5 Nov 2017, Andreas Tobler wrote: Pushed on all active branches, 8/7/6. Saw that, thank you. Very well done, Andreas! I should have gcc8-devel updated in the next 24 hours, gcc7-devel and gcc6-devel over the week as new snapshots are released. Cool thx! If you could do the gcc* branches, yes please. Once the respective -devel ports are updated, I'll take care of the corresponding stable ports. Patch available if you want. (applicable to all gcc* ports, 5-8) I got one request to have the patch also in gcc5 Let's see. First I want to address the five newer ports, then possibly this one (though gcc5 is hardly used). Sure, but I can understand comment #13 of the pr mentioned. Even if hardly used, consistency is always good :) Andreas ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Segfault in _Unwind_* code called from pthread_exit
On 01.11.17 14:21, Gerald Pfeifer wrote: On Wed, 1 Nov 2017, Tijl Coosemans wrote: Please commit it to the ports tree as well, because there are reports that ftp/curl can trigger the problem. What Andreas and me usually are doing is that he commits fixes upstream (from HEAD down to release branches), I pick them up when updating the gcc*-devel ports, and if important he temporarily adds patches to the gcc* ports until the next release obsoletes them. Andreas, I can take of the gcc* ports this time once you have pushed things upstream. Pushed on all active branches, 8/7/6. If you could do the gcc* branches, yes please. I got one request to have the patch also in gcc5, see in the original (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82635). It's up on you if we will support this. I don't mind running a test on gcc-5.5. Let me know. Gruss, Andreas ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Build failed: /usr/src/share/mk/bsd.obj.mk" line 89: Malformed conditional
On Sun, Nov 05, 2017 at 08:13:27AM -0800, Simon J. Gerraty wrote:
> Simon J. Gerraty wrote:
> ...
> > I think I might have a fix for that.
>
> Or rather I know what the issue is - RELDIR isn't defined because
> .CURDIR isn't under SRCTOP,
> if OBJTOP were defined at that point, the fix is trivial, but
> in the current tree that may not be so.
> If .CURDIR isn't under SRCTOP, RELDIR is of questionable value anyway.
>
> For now you can avoid the error with below.
>
> Index: share/mk/bsd.obj.mk
> ===
> --- share/mk/bsd.obj.mk (revision 325436)
> +++ share/mk/bsd.obj.mk (working copy)
> @@ -85,7 +85,7 @@
> CANONICALOBJDIR:=/usr/obj${.CURDIR}
> .endif
>
> -.if defined(SRCTOP) && \
> +.if defined(RELDIR) && \
> (${CANONICALOBJDIR} == /${RELDIR} || ${.OBJDIR} == /${RELDIR})
> .error .OBJDIR incorrectly set to /${RELDIR}
> .endif
>
I had checked the svn-head before I saw the above, and noted bdrewery@'s
mention of:
Index: share/mk/bsd.obj.mk
===
--- share/mk/bsd.obj.mk (revision 325433)
+++ share/mk/bsd.obj.mk (working copy)
@@ -85,7 +85,7 @@
CANONICALOBJDIR:=/usr/obj${.CURDIR}
.endif
-.if defined(SRCTOP) && \
+.if defined(SRCTOP) && defined(RELDIR) && \
(${CANONICALOBJDIR} == /${RELDIR} || ${.OBJDIR} == /${RELDIR})
.error .OBJDIR incorrectly set to /${RELDIR}
.endif
which I just tried, and that got through the issue:
FreeBSD g1-252.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #3
r325433M/325433:1200052: Sun Nov 5 04:27:43 PST 2017
r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64
Peace,
david
--
David H. Wolfskill da...@catwhisker.org
Unsubstantiated claims of "Fake News" are evidence that the claimant lies again.
See http://www.catwhisker.org/~david/publickey.gpg for my public key.
signature.asc
Description: PGP signature
Re: Build failed: /usr/src/share/mk/bsd.obj.mk" line 89: Malformed conditional
Simon J. Gerraty wrote:
> David Wolfskill wrote:
> > ===> Building for nvidia-driver-340-340.102
> > ===> src (all)
> > make[6]: "/usr/src/share/mk/bsd.obj.mk" line 89: Malformed conditional
> > (defined(SRCTOP) && (${CANONICALOBJDIR} == /${RELDIR} || ${.OBJDIR} ==
> > /${RELDIR}))
> > make[6]: Fatal errors encountered -- cannot continue
> > make[6]: stopped in
> > /common/S4/obj/usr/src/amd64.amd64/sys/CANARY/common/ports/x11/nvidia-driver-340/work/NVIDIA-FreeBSD-x86_64-340.102/src
> > *** Error code 1
>
> I think I might have a fix for that.
Or rather I know what the issue is - RELDIR isn't defined because
.CURDIR isn't under SRCTOP,
if OBJTOP were defined at that point, the fix is trivial, but
in the current tree that may not be so.
If .CURDIR isn't under SRCTOP, RELDIR is of questionable value anyway.
For now you can avoid the error with below.
Index: share/mk/bsd.obj.mk
===
--- share/mk/bsd.obj.mk (revision 325436)
+++ share/mk/bsd.obj.mk (working copy)
@@ -85,7 +85,7 @@
CANONICALOBJDIR:=/usr/obj${.CURDIR}
.endif
-.if defined(SRCTOP) && \
+.if defined(RELDIR) && \
(${CANONICALOBJDIR} == /${RELDIR} || ${.OBJDIR} == /${RELDIR})
.error .OBJDIR incorrectly set to /${RELDIR}
.endif
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Build failed: /usr/src/share/mk/bsd.obj.mk" line 89: Malformed conditional
David Wolfskill wrote:
> ===> Building for nvidia-driver-340-340.102
> ===> src (all)
> make[6]: "/usr/src/share/mk/bsd.obj.mk" line 89: Malformed conditional
> (defined(SRCTOP) && (${CANONICALOBJDIR} == /${RELDIR} || ${.OBJDIR} ==
> /${RELDIR}))
> make[6]: Fatal errors encountered -- cannot continue
> make[6]: stopped in
> /common/S4/obj/usr/src/amd64.amd64/sys/CANARY/common/ports/x11/nvidia-driver-340/work/NVIDIA-FreeBSD-x86_64-340.102/src
> *** Error code 1
I think I might have a fix for that.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Build failed: /usr/src/share/mk/bsd.obj.mk" line 89: Malformed conditional
Am Sun, 5 Nov 2017 04:44:44 -0800
David Wolfskill schrieb:
> This is a self-hosted amd64; the failure was during the (re)build of the
> kernel module for x11/nvidia-driver-340 as the final bit of "make
> buildkernel":
>
> ...
> >>> stage 3.1: building everything
> ...
> ===> nvidia-driver-340-340.102 depends on file:
> /usr/local/libdata/pkgconfig/xext.pc
> - found ===> Configuring for nvidia-driver-340-340.102
> ===> Building for nvidia-driver-340-340.102
> ===> src (all)
> make[6]: "/usr/src/share/mk/bsd.obj.mk" line 89: Malformed conditional
> (defined(SRCTOP)
> && (${CANONICALOBJDIR} == /${RELDIR} || ${.OBJDIR} == /${RELDIR})) make[6]:
> Fatal
> errors encountered -- cannot continue make[6]: stopped
> in
> /common/S4/obj/usr/src/amd64.amd64/sys/CANARY/common/ports/x11/nvidia-driver-340/work/NVIDIA-FreeBSD-x86_64-340.102/src
> *** Error code 1
>
> Stop.
> make[5]: stopped
> in
> /common/S4/obj/usr/src/amd64.amd64/sys/CANARY/common/ports/x11/nvidia-driver-340/work/NVIDIA-FreeBSD-x86_64-340.102
> ===> Compilation failed unexpectedly.
>
>
> As noted, the previous successful build in head/amd64 was r325383:
>
> FreeBSD g1-252.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #2
> r325383M/325385:1200052: Sat Nov 4 06:54:48 PDT 2017
> r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY
> amd64
>
>
> I have 'PORTS_MODULES=x11/nvidia-driver-340' in src.conf -- as I'm
> rebuilding the kernel fairly often (daily), it seemed to make sense
> to ensure that the nvidia kmod stays synchronized.
>
> Any suggestions for evasive maneuvers? Thanks!
>
> Peace,
> david
Me, too, here. Reported this yesterday in to src list. It is the very same when
building
emulators/virtualbox-ose-kmod among x11/nvidia-driver.
--
O. Hartmann
Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
pgpVpqqS0pcHB.pgp
Description: OpenPGP digital signature
Build failed: /usr/src/share/mk/bsd.obj.mk" line 89: Malformed conditional
This is a self-hosted amd64; the failure was during the (re)build of the
kernel module for x11/nvidia-driver-340 as the final bit of "make
buildkernel":
...
>>> stage 3.1: building everything
...
===> nvidia-driver-340-340.102 depends on file:
/usr/local/libdata/pkgconfig/xext.pc - found
===> Configuring for nvidia-driver-340-340.102
===> Building for nvidia-driver-340-340.102
===> src (all)
make[6]: "/usr/src/share/mk/bsd.obj.mk" line 89: Malformed conditional
(defined(SRCTOP) && (${CANONICALOBJDIR} == /${RELDIR} || ${.OBJDIR} ==
/${RELDIR}))
make[6]: Fatal errors encountered -- cannot continue
make[6]: stopped in
/common/S4/obj/usr/src/amd64.amd64/sys/CANARY/common/ports/x11/nvidia-driver-340/work/NVIDIA-FreeBSD-x86_64-340.102/src
*** Error code 1
Stop.
make[5]: stopped in
/common/S4/obj/usr/src/amd64.amd64/sys/CANARY/common/ports/x11/nvidia-driver-340/work/NVIDIA-FreeBSD-x86_64-340.102
===> Compilation failed unexpectedly.
As noted, the previous successful build in head/amd64 was r325383:
FreeBSD g1-252.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #2
r325383M/325385:1200052: Sat Nov 4 06:54:48 PDT 2017
r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64
I have 'PORTS_MODULES=x11/nvidia-driver-340' in src.conf -- as I'm
rebuilding the kernel fairly often (daily), it seemed to make sense
to ensure that the nvidia kmod stays synchronized.
Any suggestions for evasive maneuvers? Thanks!
Peace,
david
--
David H. Wolfskill da...@catwhisker.org
Unsubstantiated claims of "Fake News" are evidence that the claimant lies again.
See http://www.catwhisker.org/~david/publickey.gpg for my public key.
signature.asc
Description: PGP signature
