Re: r111 build error

2018-12-12 Thread Ed Maste
On Wed, 12 Dec 2018 at 10:19, Ed Maste wrote: > > While we could take this to > root cause I think the most expedient fix is probably just to check > for evidence of clang 6 in the object tree, and rm the .depend files > and objects if found. A patch implementing this is avail

Re: r111 build error

2018-12-12 Thread Ed Maste
On Wed, 12 Dec 2018 at 07:35, Lev Serebryakov wrote: > > On 12.12.2018 14:59, Dimitry Andric wrote: > > ld: error: undefined symbol: clang::CallExpr::getLocStart() const > >>> referenced by MacOSXAPIChecker.cpp:86 > >>>

Re: GNU binutils 2.17.50 retirement planning

2018-11-26 Thread Ed Maste
On Mon, 26 Nov 2018 at 10:52, Ed Maste wrote: > > The most significant issue is > sys/crypto/skein/amd64/skein_block_asm.s, and it makes extensive use > of GNU macro extensions. I have looked at nasm and yasm but believe > the macro extension support in those is less developed

Re: GNU binutils 2.17.50 retirement planning

2018-11-26 Thread Ed Maste
On Sat, 24 Nov 2018 at 17:24, Charlie Li wrote: > > some Makefile logic in stand/i386/btx specify a > hard-coded /usr/bin/as without bootstrapped binutils, necessitating a > symlink. Which logic specifically? I can't seem to find it. > If it is true that the only assembly files that clang IAS

Re: GNU binutils 2.17.50 retirement planning

2018-11-26 Thread Ed Maste
On Sun, 25 Nov 2018 at 07:52, David Chisnall wrote: > > We probably need to kill ld.bfd before 12.0. It predates ifunc and so > interprets anything with an ifunc as requiring a copy relocation. I posted https://reviews.freebsd.org/D18340 to stop installing ld.bfd when LLD_IS_LD is enabled.

GNU binutils 2.17.50 retirement planning

2018-11-23 Thread Ed Maste
For some time we have been incrementally working to retire the use of obsolete GNU Binutils 2.17.50 tools. At present we still install three binutils by default: as ld.bfd objdump The intent is to retire all of these by FreeBSD 13. Depending on tool and architecture we will just remove it,

ctm(1) deprecation in the FreeBSD base system?

2018-10-22 Thread Ed Maste
The ctm(1) client remains in the FreeBSD base system, although FreeBSD-hosted ctm infrastructure was shut down some time ago. I suspect it is time to remove it from the base system (perhaps making a port). How much use does ctm have these days? ___

Re: HEADS-UP: OpenSSL 1.1.1 in 12.0

2018-10-10 Thread Ed Maste
On Wed, 10 Oct 2018 at 18:11, O. Hartmann wrote: > > security/libssh This one is open as PR 228895. If there are other ports that you're trying to build and are failing with OpenSSL 1.1.1 please check PR 228865 and 231931 to see if it is already listed as a dependency. You can see all of the

Re: HEADS-UP: OpenSSL 1.1.1 in 12.0

2018-10-10 Thread Ed Maste
On Tue, 9 Oct 2018 at 23:15, Michael Butler wrote: > > On 10/9/18 5:34 PM, Glen Barber wrote: > > OpenSSL has been updated to version 1.1.1 as of r339270. > > > > It is important to rebuild third-party packages before running: > > > > # make -C /usr/src delete-old && make -C /usr/src

Re: Enabling the WITH_REPRODUCIBLE_BUILD knob for 12.0-REL

2018-09-27 Thread Ed Maste
On 27 September 2018 at 06:46, tech-lists wrote: > > So, I want to know where and when each system was compiled. > Why lose this information by default? This comes down to the simple fact that our build / release process does not currently distinguish between building a world or kernel that's

Re: change in uname -a behaviour between 12-ALPHA5 and 12-ALPHA7

2018-09-26 Thread Ed Maste
On 26 September 2018 at 12:20, tech-lists wrote: > On 26/09/2018 14:34, Andrey Fesenko wrote: >> >> See WITH_REPRODUCIBLE_BUILD >> >> https://lists.freebsd.org/pipermail/freebsd-current/2018-September/071125.html > > > Thanks, I was unaware of the change till now. Somehow missed that thread.

Re: Buildowrld tries to use old ld, and fails

2018-09-25 Thread Ed Maste
On 25 September 2018 at 02:55, wrote: > >> The normal procedure shouldn't need any LD= overrides; is there >> something unique in your build? Any src.conf settings? > > Indeed, I had "WITHOUT_LLD_BOOTSTRAP=yes" in src.conf. Not sure how > that line made it into this file on a number of my

Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored

2018-09-24 Thread Ed Maste
On 23 September 2018 at 07:31, Michael Tuexen wrote: > Using this patch I was able to build/install world and kernel on an i386 > system. > However, after removing it, I can't build world then. When trying to compile a > kernel "the old way" I end up with: > > tuexen@head:~/head/sys/i386/conf %

Re: Buildowrld tries to use old ld, and fails

2018-09-24 Thread Ed Maste
On 23 September 2018 at 21:18, wrote: > > Howdy! > > Since a couple months ago, the world on -CURRENT cannot be built using > the normal procedure: >time env LD=ld.lld make -j6 buildworld buildkernel The normal procedure shouldn't need any LD= overrides; is there something unique in your

Re: r338902 error buildworld on i386

2018-09-24 Thread Ed Maste
On 24 September 2018 at 06:43, Alex V. Petrov wrote: > ===> lib/libc (cleandir) > make[4]: "/usr/src/lib/libc/Makefile" line 26: i386 libc requires linker > ifunc support > *** Error code 1 Please try r338903. ___ freebsd-current@freebsd.org mailing

Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored

2018-09-21 Thread Ed Maste
On 21 September 2018 at 15:31, Mark Johnston wrote: > > Perhaps the following? It's not quite right since it'll still use > -zifunc-noplt with an external LLVM toolchain, but I can't seem to > figure out how to define a linker feature for only non-cross toolchains. > In any case, we're going to

Re: building head -r338675 with devel/amd64-gcc: /usr/local/x86_64-unknown-freebsd12.0/bin/ld: warning: -z ifunc-noplt ignored

2018-09-21 Thread Ed Maste
On 21 September 2018 at 01:59, Mark Millard via freebsd-toolchain wrote: > In looking into another report about using devel/amd64-gcc to buld > head I tried a build of -r338675 ( with WERROR= ). It got: > ... > > Question: > > Is ignoring "-z ifunc-noplt" a problem for using what > is built?

Re: FreeBSD EFI projects

2018-09-19 Thread Ed Maste
On 19 September 2018 at 10:34, Rodney W. Grimes wrote: > > You would be hard pressed to find a system with a 64 bit CPU that > could run 64 bit FreeBSD that had a 32 bit EFI implementation. The Minnowboard Turbot has an Atom E3826, and has four precompiled Tianocore UEFI firmware releases

Re: just a FYI

2018-09-19 Thread Ed Maste
On 19 September 2018 at 09:28, Jeffrey Bouquet wrote: > /usr/ports/security/lockdown [ sorry if this is a PR or for ports- ] Unfortunately this port has no maintainer, so fixing this is going to need someone to take an interest in the port. I had a quick look at the script and it looks like it

Re: FreeBSD EFI projects

2018-09-17 Thread Ed Maste
On 17 September 2018 at 14:17, Warner Losh wrote: > Items on my list are: > > (1) Retiring boot1.efi entirely before 13.0. It was originally designed to > be a small, never changing blob we'd toss into an ESP and have all the > smarts in loader.efi. I'd go further than this: it was originally

Re: Enabling the WITH_REPRODUCIBLE_BUILD knob for 12.0-REL

2018-09-11 Thread Ed Maste
On 11 September 2018 at 07:35, Tomoaki AOKI wrote: > I prefer releng, rather than stable, to make it default. > Binary releases requiring reproducible builds are built from > release and releng branches. This might be the reasonable long-term strategy, but we don't yet have experience running

Re: Enabling the WITH_REPRODUCIBLE_BUILD knob for 12.0-REL

2018-09-10 Thread Ed Maste
On 10 September 2018 at 14:52, Ed Maste wrote: > > I brought this up on -arch in 2015... That said, the kgdb -n issue was brought up in the old thread and it seems I did forget about it. I don't think we should cater too much to the needs of the deprecated in-tree kgdb, but we should mak

Re: Enabling the WITH_REPRODUCIBLE_BUILD knob for 12.0-REL

2018-09-10 Thread Ed Maste
On 10 September 2018 at 13:57, Rodney W. Grimes wrote: >> >> I know a number of developers want to keep the metadata for their own >> builds at least. > > And we do not really know what the users position is on this... If users are building FreeBSD from source they can set the knob however they

Re: Enabling the WITH_REPRODUCIBLE_BUILD knob for 12.0-REL

2018-09-10 Thread Ed Maste
On 10 September 2018 at 12:51, Rodney W. Grimes wrote: > > Why not just turn this on and leave it on? I know a number of developers want to keep the metadata for their own builds at least. We have essentially three different levels of metadata that are arguably sensible: 1. Major/minor

Re: Enabling the WITH_REPRODUCIBLE_BUILD knob for 12.0-REL

2018-09-10 Thread Ed Maste
On 10 September 2018 at 11:11, Jonathan Anderson wrote: > Hi Ed, > > I think that sounds great. In the future, could we go even further and, by > default, only emit date/user/path if the source tree is “dirty” with respect > to SVN? If the build really is reproducible, that data should only be >

Enabling the WITH_REPRODUCIBLE_BUILD knob for 12.0-REL

2018-09-10 Thread Ed Maste
The FreeBSD base system is a reproducible build[1] with a minor exception: the build metadata (timestamps, user, hostname, etc.) included in the kernel and loader. With the default, non-reproducible build the kernel ident looks like: FreeBSD 12.0-ALPHA5 #4 r338195: Mon Jan 1 10:11:12 EDT 2018

Re: github freebsd and svn freebsd

2018-09-06 Thread Ed Maste
On 6 September 2018 at 20:11, Warner Losh wrote: > >> Assuming we're confident the issue in the svn mirroring process is >> fixed and will not recur we can redo the conversion, with a one-time >> change to all hashes from the offending commit on, and they would not >> change again in the future.

Re: github freebsd and svn freebsd

2018-09-06 Thread Ed Maste
On 4 September 2018 at 06:53, Kurt Jaeger wrote: > > The github repo isn't official, because there are still some > consistency issues. The consistency problem is: If an repo-copy > from svn to git is done, how can that repo-copy be done a second > time and still keep the same commit ids (in the

Re: kldref: unhandled relocation type 2

2018-08-17 Thread Ed Maste
On 8 August 2018 at 13:27, Warner Losh wrote: > >> % /usr/obj/usr/src/i386.i386/usr.sbin/kldxref/kldxref /boot/kernel >> kldxref: unhandled relocation type 2 >> (40+ messages...) > > > Oh, wait: relocation type, not module info That's not me, that's ed and > the new linker I think, or Dimitry

i386 top reporting nan% or inf% WCPU

2018-07-24 Thread Ed Maste
I recently merged my work in progress tree up to r336665 and built a i386 VM image. Running the image in QEMU (qemu-system-x86_64) and executing 'top' I see the WCPU column reported as either nan% or inf% for all processes. Prior to today I hadn't built or tested i386 in a while, so I am not sure

Re: Tool Chain Migration: objdump users, please test llvm-objdump

2018-06-21 Thread Ed Maste
On 21 June 2018 at 09:09, Ed Maste wrote: > > We'll also need a man page. I took a quick look at this, and in doing so found that the output from "llvm-objdump --help" appears to be missing a large number of single-letter options, so one more thing to sort out. As it happens the

Re: Tool Chain Migration: objdump users, please test llvm-objdump

2018-06-21 Thread Ed Maste
On 20 June 2018 at 17:26, Alexander Richardson wrote: > > When I made the change to use llvm-objdump in CheriBSD I had to change the > objdump flags from -xrsSd to -r -s -p -S -d -h -l -t. Ah yes, I recall discussing this now. Per GNU objdump's man page, -x is equivalent to -a -f -h -p -r -t.

Re: Tool Chain Migration: objdump users, please test llvm-objdump

2018-06-20 Thread Ed Maste
On 20 June 2018 at 18:25, Shawn Webb wrote: > > Would you like me to quantify the compilation breakages due to the > full llvm toolchain switch? If so, I can do that after July 12th. Thanks Shawn, right now I'm interested specifically in llvm-objdump, with the goal of sorting it out in advance

Tool Chain Migration: objdump users, please test llvm-objdump

2018-06-20 Thread Ed Maste
Work is in progress to migrate fully to modern and permissively licensed components for the tool chain. This includes moving away from the three obsolete binutils components that are still in the base system (as, ld, objdump). objdump is a tool to report information about binary objects (such as

Re: A head buildworld race visible in the ci.freebsd.org build history

2018-06-18 Thread Ed Maste
On 18 June 2018 at 19:29, Bryan Drewery wrote: > > The error is coming from libarchive which had a change between those > revisions: > >> >> r328332 | mm | 2018-01-24 06:24:17 -0800 (Wed, 24 Jan 2018) | 14 lines Li-Wen

Re: Boot USB memstick with MBR (WAS: Re: [RFC] Deprecation and removal of the drm2 driver)

2018-05-30 Thread Ed Maste
On 30 May 2018 at 18:08, Philip Homburg wrote: >>Strange. Can you try an updated test image of mine >>(https://people.freebsd.org/~emaste/mini-image-2018-05-28.xz) Oops - that should have been https://people.freebsd.org/~emaste/mini-image-2018-05-28-amd64.xz But the most recent snapshot images

Re: Boot USB memstick with MBR (WAS: Re: [RFC] Deprecation and removal of the drm2 driver)

2018-05-30 Thread Ed Maste
On 25 May 2018 at 04:51, Philip Homburg wrote: > > I have bad news and some good news. > > The bad news is that with this image the USB stick doesn't get recognized as > a boot device. Same as with the 11.2-BETA2 images. At least it's not a regression. > The good news is that if I completely

Re: Boot USB memstick with MBR (WAS: Re: [RFC] Deprecation and removal of the drm2 driver)

2018-05-24 Thread Ed Maste
On 23 May 2018 at 17:51, Philip Homburg wrote: > I tried both FreeBSD-11.2-BETA2-amd64-bootonly.iso.xz and > FreeBSD-11.2-BETA2-amd64-mini-memstick.img.xz on a Dell PowerEdge 2950 > BIOS version 2.7.0. With both images, the USB stick is not recognized. Can you download

Re: [RFC] Deprecation and removal of the drm2 driver

2018-05-23 Thread Ed Maste
On 23 May 2018 at 05:48, Philip Homburg wrote: > > Turns out, you can't install FreeBSD using a USB stick image because the > BIOS only support MBR. No idea why MBR support was dropped for the USB images. We haven't "dropped" MBR support, and our amd64 memstick images

Re: HEADS-UP: Linker issues building amd64 kernels with config & make

2018-05-14 Thread Ed Maste
On 14 May 2018 at 18:05, Julian H. Stacey wrote: > > I guess this explains : > Date: Sun, 13 May 2018 20:26:38 +0200 > Subject: cd /sys/amd64/compile/GENERIC;make cleandepend; make cleandepend > .svn_revision 333575 > linking kernel.full >

HEADS-UP: Linker issues building amd64 kernels with config & make

2018-05-14 Thread Ed Maste
As of r333461 the amd64 kernel makes use of ifuncs, and requires support in the linker. A safety belt added in r333470 enforces this, and will produce an explicit error if the linker does not support ifuncs. lld is the default bootstrap linker for amd64 and has ifunc support. The typical 'make

Deprecating the lmc(4) driver

2018-04-24 Thread Ed Maste
The lmc(4) driver supports hardware for a number of legacy interfaces, including EIA612/613, T1/E1, T3, etc. The driver's license is ambiguous and attempts to contact the author failed. I would like to remove this driver from 12.0, and have a deprecation notice in review D15182 [1]; I would

HEADS-UP: Deprecation of legacy (v3) password database support

2018-04-20 Thread Ed Maste
FreeBSD password databases (/etc/pwd.db, /etc/spwd.db) can contain records in one or both of two versions: * v3, a legacy architecture-dependent format * v4, the current architecture- and endian-independent format When v4 support was added in 2003 (r113596) pwd_mkdb emitted both v3 and v4

Re: snapshot of april 12th wont boot at all

2018-04-17 Thread Ed Maste
On 17 April 2018 at 11:17, Shawn Webb wrote: > > HardenedBSD enables PTI regardless of underlying CPU by default. We've > found that some older AMD CPUs have issues with PTI as currently > implemented. The oldest AMD CPU I have is a FX-6100, and FreeBSD-CURRENT works

Re: clang manual page?

2018-04-07 Thread Ed Maste
On 6 April 2018 at 07:25, Dimitry Andric wrote: > > With lld there wasn't even *any* form of command line documentation > yet, which is why Ed slapped together a man page (that could probably > still use more details). It should really be upstreamed, in Sphinx's > RST format,

Re: Can't load linux64.ko module

2018-04-04 Thread Ed Maste
On 3 April 2018 at 12:26, Steve Kargl wrote: > Booting a kernel from > % uname -a > FreeBSD sleepdirt 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r331370: \ > Thu Mar 22 13:41:30 AKDT 2018 \ > kargl@sleepdirt:/usr/obj/usr/src/amd64.amd64/sys/SLEEPDIRT amd64 > >

Re: Heads-up: linker (lld) changes for amd64 coming soon

2018-03-27 Thread Ed Maste
On 27 March 2018 at 02:20, Antoine Brodin wrote: >> 1. Kostik (kib@) has a patch to start using kernel ifunc, with the >> first use being Supervisor Mode Access Prevention (SMAP) on amd64. >> This relies on linker support that is available in the in-tree lld and >> in

Heads-up: linker (lld) changes for amd64 coming soon

2018-03-26 Thread Ed Maste
Some changes related to the amd64 linker are nearly ready to be committed (within a week or three), so I'm sending this notice to request any final comments or concerns before these changes are made. 1. Kostik (kib@) has a patch to start using kernel ifunc, with the first use being Supervisor

Re: Performance Benchmark for PTI (aka Meltdown mitigation)

2018-03-09 Thread Ed Maste
On 9 March 2018 at 07:01, Slawa Olhovchenkov wrote: > On Thu, Mar 08, 2018 at 05:04:11PM -0500, Arshan Khanifar wrote: > >> Executive Summary: >> - The PTI feature increases the system call times by more than 100%. >> - As a macrobenchmark, buildworld was used. Wall clock and

Re: Conflict between FreeBSD-binutils and FreeBSD-lld packages

2018-03-03 Thread Ed Maste
On 2 March 2018 at 04:34, Tobias Kortkamp wrote: > Building pkgbase packages with r330236 results in FreeBSD-binutils and > FreeBSD-lld packages conflicting with each other. Both want to > install /usr/share/man/man1/ld.1.gz Thanks for the report; this should be fixed as of

Re: Question mark on Lua menu box

2018-03-02 Thread Ed Maste
On 2 March 2018 at 07:06, Renato Botelho wrote: > Kyle, > > I've moved to Lua loader to help testing and it worked fine. The only > odd thing I noted is the menu box with odd chars as you can see at [1]. Hi Renato, thanks for testing! Are you booting via BIOS or UEFI?

Re: Insta-reset-bootloop with r328166 and vm.pmap.pcid_enabled=1

2018-01-26 Thread Ed Maste
On 25 January 2018 at 17:21, Ian FREISLICH wrote: >> Yes, this is how it is currently behaves. >> PCID can be used to optimize PTI, see https://reviews.freebsd.org/D13985. >> It is used for very differrent algorithm when PTI=1, comparing with PTI=0. > > Maybe there

Re: r327359: cylinder checksum failed: cg0, cgp: 0x4515d2a3 != bp: 0xd9fba319 Dec 30 23:29:24 <0.2>

2018-01-12 Thread Ed Maste
On 4 January 2018 at 03:10, Michael Tuexen wrote: > > Not sure this helps: But we have seen this also after system panics > when having soft update journaling enabled. Having soft update journaling > disabled, we do not observed this after several panics. > Just to be clear:

Re: LLD: man pages missing?

2018-01-10 Thread Ed Maste
On 9 January 2018 at 20:38, Ed Maste <ema...@freebsd.org> wrote: > > What we have so far is in review at > https://reviews.freebsd.org/D13813. It's still rather bare-bones, but > I would like to commit it soon so that we have something to start > from, and continue fleshing i

Re: LLD: man pages missing?

2018-01-09 Thread Ed Maste
On 25 December 2017 at 15:16, O. Hartmann wrote: > I have installed most recent CURRENT as of r327219 with LLD_IS_LD=YES set > via /etc/src.conf. > > I try to find some options and tried "man ld", "man lld" and "ld.lld". In the > the latter > two cases there can nothing

Re: LLD: man pages missing?

2017-12-26 Thread Ed Maste
On 25 December 2017 at 15:25, Dimitry Andric wrote: > > Since lld is now approaching a quite usable state, maybe it is time for > a request to upstream to provide [a manpage]. ;) Yes, it would've been nice if an upstream man page was created early on and had been kept up to

Re: Emacs and LLD

2017-11-20 Thread Ed Maste
On 3 November 2017 at 11:29, Tobias Kortkamp wrote: > > My src.conf has WITH_LLD_IS_LD=yes and reading > https://bugs.freebsd.org/214864 leads me to believe that it's somehow > responsible for the problems I have with Emacs. Yes, the emacs build does some rather unusual things

Re: [HEADS UP] posix_fallocate support removed from ZFS, lld affected

2017-11-13 Thread Ed Maste
On 7 November 2017 at 13:12, Andriy Gapon wrote: > > I hope that lld is not that widely used now. > But I admit that I put the cart before the horse. > I didn't expect that posix_fallocate is used in the development toolchain and > I > didn't try to check for it. For amd64 it

Re: [HEADS UP] posix_fallocate support removed from ZFS, lld affected

2017-11-06 Thread Ed Maste
On 6 November 2017 at 10:56, Ian Lepore wrote: > > Oh, right. lld != ld. Indeed, but this will be a problem for the arm64 package builds if they use ZFS and an 11.x userland on a new kernel. We probably need to bring the lld change in as an errata.

Re: svn commit: r325320 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs [breaks lld on zfs: lld uses fallocate]

2017-11-04 Thread Ed Maste
On 4 November 2017 at 07:41, Andriy Gapon wrote: > On 04/11/2017 12:32, Mark Millard wrote: >> if (int Err = ::posix_fallocate(FD, 0, Size)) { >> if (Err != EOPNOTSUPP) >> return std::error_code(Err, std::generic_category()); >> } > > The commit message that you

Re: SIGSEGV in /bin/sh after r322740 -> r322776 update

2017-08-22 Thread Ed Maste
On 22 August 2017 at 07:46, David Wolfskill wrote: > > lldb's notion of the backtrace was fairly non-useful: > g1-252(11.1-S)[7] lldb -c sh.core Try: % lldb /bin/sh -c sh.core ___ freebsd-current@freebsd.org mailing list

Re: buildworld fails while building static clang library

2017-08-14 Thread Ed Maste
On 7 August 2017 at 00:32, Aijaz Baig wrote: > That was some pretty relevant information Ed. Thanks. Even though it's not a direct cause of the problem you encountered I wanted to make sure a there was comprehensive reply to Dimitry's question. > Nonetheless, as I have

Re: buildworld fails while building static clang library

2017-08-06 Thread Ed Maste
On 5 August 2017 at 16:16, Dimitry Andric wrote: > > I remember there being an issue with ar and/or ranlib choking when the > .a files become too big. Ed, does that ring any bells? Our ar (and ranlib, which is the same binary) will produce a corrupt symbol table if the .a

Re: r320183 (rpc.lockd cleanup) breaks virtualbox-ose build

2017-07-21 Thread Ed Maste
On 11 July 2017 at 12:44, Don Lewis wrote: > This is a really strange problem ... > > Last week I upgraded my 12.0-CURRENT package build box from r318774 to > r320570. I also upgraded the poudriere jail to match. When I went to > build packages, the virtualbox-ose build

Re: Final Call for 2017Q2 Quarterly Status Reports

2017-07-07 Thread Ed Maste
On 30 June 2017 at 21:27, Benjamin Kaduk wrote: > > The preferred and easiest submission method is to use the XML generator [1] > > [1] https://www.FreeBSD.org/cgi/monthly.cgi Note that Chrome has a bug when attempting to save the output of monthly.cgi, and your work will be

Re: After ino64 update: devel/libunwind failure: cannot preempt symbol '_Ux86_64_local_addr_space' defined

2017-05-30 Thread Ed Maste
On 30 May 2017 at 12:49, O. Hartmann wrote: > > I got a kind of confused, since libunwind seemingly compiles on one box with > both ino64 > AND WITH_LLD_IS_LD, while it failed after an update of a bunch of systems > towards ino64. So was this just confusion over what

Re: ino64 status update and upgrade caution

2017-05-30 Thread Ed Maste
On 29 May 2017 at 10:49, Ed Maste <ema...@freebsd.org> wrote: > The ino64 project was committed to src last week[1][2] with > UPDATING notes added shortly thereafter [3][4][5]. I've now added an anti-foot-shooting test[6] which invokes the new rescue binary prior to proceeding with

Re: After ino64 update: devel/libunwind failure: cannot preempt symbol '_Ux86_64_local_addr_space' defined

2017-05-29 Thread Ed Maste
On 29 May 2017 at 04:59, O. Hartmann wrote: > After updating several boxes running CURRENT after introduction of ino64, I > have one box which persitently rejects compiling and installing > devel/libunwind, as you can finde below. > > The box in question is running

ino64 status update and upgrade caution

2017-05-29 Thread Ed Maste
The ino64 project was committed to src last week[1][2] with UPDATING notes added shortly thereafter [3][4][5]. As some people have been tripped up by the ino64 change I want to emphasize again that the upgrade procedure described in UPDATING should be followed exactly. The reboot after installing

Re: Another INO64 Disaster

2017-05-27 Thread Ed Maste
On 27 May 2017 at 12:25, Thomas Laus wrote: > After the > first boot, I tried to install the pkg system. The first fault said > that the libarchive.so.6 was missing. Yes, the most recent package set available is built against a pre-ino64 world and depends on older versions of

Re: (head users) 64-bit inodes: Packages heads up and Poudriere errors

2017-05-26 Thread Ed Maste
On 26 May 2017 at 12:18, Kurt Jaeger wrote: > Hi! > >> For those running FreeBSD head, the ABI was majorly changed in r318736 >> for 64-bit inodes. This change was *backwards compatible* but not >> *forward compatible*. This is normal and expected. > > Is any fall-out from this

Re: FYI: amd64 built with WITH_LLD_IS_LD= vs. devel/libunwind : cannot preempt symbol (for various symbols)

2017-04-16 Thread Ed Maste
On 16 April 2017 at 04:10, Mark Millard wrote: > Context: amd64 FreeBSD -r316952 as a VirtualBox guest > that was built using WITH_LLD_IS_LD= . ports -r438577. > > x11/xorg-minimal indirectly gets to devel/libunwind and > devel/libunwind fails to build from source: > > > ---

Re: vt(4) bugs needing attention

2017-04-03 Thread Ed Maste
On 1 April 2017 at 13:28, Ernie Luzar wrote: > > Is anyone working the these outstanding vt(4) bug reports? I am not aware of anyone working on these right now. > Bug 210446 - vt(4) when switching between virtual consoles there is a 4 > second hesitation in graph mode. >

Re: cross compiling freebsd-head is sigh, now broken - thanks libllvm

2017-03-20 Thread Ed Maste
On 19 March 2017 at 03:00, Adrian Chadd wrote: > gcc version 5.3.0 (FreeBSD Ports Collection for mips) > > ... so uhm, why are we building libllvm? As of the Clang 4.0.0 import we build Clang by default, on all architectures other than those unsupported by Clang, if the

Re: Problem with WITH_LLD_IS_LD

2017-03-03 Thread Ed Maste
On 3 March 2017 at 12:24, Jochen Neumeister wrote: > Hi current@ > > I have a PR 217519 because of devel/pear: When WITH_LLD_IS_LD is set, the > stage phase for devel/pear breaks. Yes, there are issues building a number of ports with LLD at present. There are some hacks /

Re: ASLR

2017-01-24 Thread Ed Maste
On 18 January 2017 at 17:56, Piotr Kubaj wrote: > It should also be stated properly that this patch doesn't implement ASLR, but > ASR. For better or worse the term ASLR is today in common use to refer to a number of different approaches. Using what has become a generic term

Re: vt(4) chops off the leftmost three columns

2017-01-12 Thread Ed Maste
On 12 January 2017 at 18:50, Alan Somers wrote: > I've seen three separate machines where FreeBSD11's vt(4) driver chops > off the leftmost three columns of the screen. Rendering simply starts > at the beginning of the fourth column. In all cases, setting > "kern.vty=sc"

Call for Testing: Switching back to our BSD licensed dtc(1)

2016-07-19 Thread Ed Maste
dtc(1) is the Device Tree Compiler, used for embedded builds. We have two versions of dtc(1) in the FreeBSD tree: a GPLv2 one from https://git.kernel.org/cgit/utils/dtc/dtc.git and a BSD licensed one in https://svn.freebsd.org/base/head/usr.bin/dtc. We switched back to the GPL one since device

Re: console in 11.0-ALPHA4

2016-06-21 Thread Ed Maste
On the topic of vgl(3) specifically, in October 2014 I wrote on this list: > vgl(3) is a graphics library for syscons(4) that provides some basic > graphics operations (e.g. some mode setting, bitmaps, boxes, > ellipses). Right now it does not support the newer vt(4) console. > > In order to help

Re: console in 11.0-ALPHA4

2016-06-20 Thread Ed Maste
On 20 June 2016 at 23:22, John Baldwin wrote: > > There are tradeoffs in both directions. Neither console is a subset of the > other. However, sc(4) is not really extendable to support the things it is > missing. vt(4) is actively worked on, and patches for the features it

Re: console in 11.0-ALPHA4

2016-06-20 Thread Ed Maste
On 20 June 2016 at 14:29, Ernie Luzar wrote: > > I found the cause of this boot time message > "vicontrol: setting cursor type: Inappropriate ioctl for device" > > In my rc.conf I had this statement > vidcontrol -c blink -h 250 > From testing it seems that vt does not handle

Re: console in 11.0-ALPHA4

2016-06-20 Thread Ed Maste
On 20 June 2016 at 12:45, Trond Endrestøl wrote: > > If you want textmode like in the old days, add this line to > /boot/loader.conf: > > hw.vga.textmode="1" One note, in textmode vt(4) is limited to cp437. The console still uses Unicode internally but has a

Re: No debug info for statically linked stuff

2016-06-03 Thread Ed Maste
On 3 June 2016 at 12:49, Eric van Gyzen wrote: > I'm running head from Tuesday (r301045). I just noticed that "ar" is > missing the debuginfo for libarchive: I discussed this with Eric off this thread, but for the sake of others this is happening because WITH_DEBUG_FILES

Re: Recent seems to have broken toolchain

2016-05-31 Thread Ed Maste
On 31 May 2016 at 12:21, Dimitry Andric wrote: > > Maybe elftoolchain's ar does something different? Assuming the .a files > are built with the system ar, of course. We don't use the ELF Tool Chain ar yet so it won't be that. (ELF Tool Chain's ar, brandelf, elfdump are updated

Re: Recent seems to have broken toolchain

2016-05-31 Thread Ed Maste
On 30 May 2016 at 15:51, Steve Kargl wrote: > > It happens with both /usr/bin/ld and /usr/local/bin/ld. I remove the > binutils port and still had the issue. I tried reverting recent changes > to elftoolchain/libelftc, the resulting tree would not build. The

Re: r299175: error: no such file or directory: '/usr/src/secure/lib/libcrypto/i386/crypt586.S'

2016-05-06 Thread Ed Maste
On 6 May 2016 at 14:47, O. Hartmann wrote: > Buildworld on r299175 fails with the error shown below: > > > [...] > error: no such file or directory: > '/usr/src/secure/lib/libcrypto/i386/crypt586.S' If this was with -DNO_CLEAN you might want to try a clean build

Re: clang is mostlikely miscompling libm

2016-03-13 Thread Ed Maste
On 13 March 2016 at 19:16, Steve Kargl wrote: > JFYI, > > It appears that clang on up-to-date current may be > miscompiling libm on at i686 class hardware. Do you have an example of the suspected miscompilation? ___

Re: Crash with ZFS between r296491 and r296548

2016-03-09 Thread Ed Maste
On 9 March 2016 at 08:28, Jean-Sébastien Pédron wrote: > On 09/03/2016 12:23, Alexander Motin wrote: >> Should be fixed by r296563. >> >> Illumos assumes full sync between kernel and world, so they are quietly >> breaking ABI as often as they want for any new

Re: Crash with ZFS between r296491 and r296548

2016-03-08 Thread Ed Maste
On 9 March 2016 at 01:39, Ed Maste <ema...@freebsd.org> wrote: > On 8 March 2016 at 18:52, Jean-Sébastien Pédron > <jean-sebastien.ped...@dumbbell.fr> wrote: >> Hi! >> >> I use Root on ZFS and my laptop doesn't boot with a kernel from r296548 >> and wor

Re: Crash with ZFS between r296491 and r296548

2016-03-08 Thread Ed Maste
On 8 March 2016 at 18:52, Jean-Sébastien Pédron wrote: > Hi! > > I use Root on ZFS and my laptop doesn't boot with a kernel from r296548 > and world from r296491 (so older than kernel). Ed hits a similar crash. > > Here are the dmesg and backtrace of zfs(8): >

Call for testing: Using ELF Tool Chain elfcopy as objcopy

2016-02-16 Thread Ed Maste
Summary: If you're willing to help test the ELF Tool Chain tools and you build -CURRENT from source, please set WITH_ELFCOPY_AS_OBJCOPY=yes in /etc/src.conf, and report any build- or run-time issues you experience with the base system, ports, or third-party software. In SVN revision 295577 I

Re: Too low PTHREAD_STACK_MIN value?

2016-01-21 Thread Ed Maste
On 11 March 2014 at 20:38, David Chisnall wrote: > On 12 Mar 2014, at 02:07, Roger Pau Monné wrote: > >> I've found out that the value PTHREAD_STACK_MIN is currently set (2048 >> bytes) seems to be way too low > > This looks like an error in your code.

Re: r294248: boot stuck: EFI loader doesn't proceed

2016-01-18 Thread Ed Maste
On 18 January 2016 at 03:10, Dimitry Andric wrote: > On 18 Jan 2016, at 07:20, O. Hartmann wrote: >> Building NanoBSD images booting off from USB Flash drives and having two GPT >> partitions, booting is stuck in the UEFI loader, presenting me with

Re: r294248: boot stuck: EFI loader doesn't proceed

2016-01-18 Thread Ed Maste
On 18 January 2016 at 15:26, Andrew Turner wrote: > > the issue was we were caching reads from the first filesystem we looked > at. I've committed the fix in r294291 to force the code to re-read on > each filesystem it looks at. Thanks Andrew - my QEMU boot failure is not

Re: Need help with New Build -- Skylake

2015-12-22 Thread Ed Maste
On 22 December 2015 at 12:39, Vijay Rjah wrote: > > The only issue i have is that the boot process takes a lot of time.. > (similar to > https://forums.freebsd.org/threads/new-motherboard-and-processor-kernel-load-very-slow.53511/ > ). the system ultimately boots, but boot times

HEADS-UP: Userland debug files enabled by default

2015-12-08 Thread Ed Maste
As of r291955 userland debug files are built and installed by default, in order to facilitate debugging. They will be built as part of the release process (in FreeBSD 11) so that they can be made available for download either at install time, or later on to debug a core file after a crash.

Does anyone use kgzip / kgzldr?

2015-11-23 Thread Ed Maste
I disconnected kgzldr from the build in r291113 because I thought kgzip was already disconnected. As it happens kgzip was disconnected only from the release builds, in r281658. kgzip / kgzldr only works on i386, and for quite some time the recommended way to use a compressed kernel has been via

Re: Panic: GPF in kernel mode in fork_exit() (prior to FS mouont)

2015-11-23 Thread Ed Maste
On 23 November 2015 at 08:33, Konstantin Belousov wrote: > > The revision 291171 changed layout of the dereferenced structure > sysentvec. Was your kernel build clean, or did you used -DNO_CLEAN or > similar option ? If yes, remove the kernel build directory and start > from

Re: libXO-ification - Why - and is it a symptom of deeper issues?

2015-11-18 Thread Ed Maste
On 18 November 2015 at 15:46, Luigi Rizzo wrote: > i was going to suggest doing ldd on the binaries or a grep on the > Makefile but the latter returns a surprisingly low number > of matches. That's because it's usually added via LIBADD=xo. My grep turns up these: bin/df,

Re: HEADS-UP: Enabling WITH_DEBUG_FILES by default

2015-10-27 Thread Ed Maste
On 11 February 2015 at 21:39, Glen Barber wrote: > Hi, > > Within the next 24 hours, I will merge the release-install-debug branch > into head, which will enable building and installing stripped debugging > files by default. > > In general, this should have no significant

  1   2   3   >