Re: HEADS UP: libllvm, libclang, and liblldb converted into shared libraries

On 27 Apr 2025, at 17:04, Shawn Webb wrote: > > On Sat, Apr 26, 2025 at 06:06:54PM +0200, Dimitry Andric wrote: ... >> Please let me know if you encounter any problems resulting due to this >> change, as I intend to MFC it. For example, I tried covering all >> incrementa

Re: HEADS UP: libllvm, libclang, and liblldb converted into shared libraries

On 27 Apr 2025, at 01:28, Yusuf Yaman wrote: > > I am a new user of 15.0-CURRENT and just updated my source tree and > noticed that there are now files to be built that have the ".pico" > extension, as a ccache user, i was enjoying fast world/kernel builds but > these files doesn't seem to get

Re: Empty structures have sizeof(1) in C++ now ?

In fact, in C having a struct without members is undefined behavior: > If the struct-declaration-list does not contain any named members, either > directly or via an anonymous structure or anonymous union, the behavior is > undefined. However, gcc allows this as an extension, and clang has appa

Re: Safe to do the usual end-of-month buildworld/buildkernel on RISC-V ?

On 31 Jan 2025, at 22:16, Dennis Clarke wrote: > >Not sure if I heard rumours correctly but perhaps someone can chime > in on this. Was there a problem wherein the SiFive RISC-V board would > panic with the latest kernel updates? Here I mean the "Unmatched". A similar panic for i386 was fix

Re: libxkbcommon version-script detection

https://github.com/xkbcommon/libxkbcommon/pull/585 -Dimitry > On 10 Jan 2025, at 13:51, Dimitry Andric wrote: > > Upstream solved this slightly differently, and it's become a bit messy: > > https://github.com/xkbcommon/libxkbcommon/commit/ebe4157d by bapt added the &

Re: libxkbcommon version-script detection

ug to get this pushed upstream? > > Peter > > >> On 10 Jan 2025, at 13:28, Dimitry Andric wrote: >> >> On 10 Jan 2025, at 12:56, Dimitry Andric wrote: >>> >>> On 10 Jan 2025, at 12:20, Peter Blok wrote: >>>> >>>> T

Re: libxkbcommon version-script detection

On 10 Jan 2025, at 12:56, Dimitry Andric wrote: > > On 10 Jan 2025, at 12:20, Peter Blok wrote: >> >> Test works ok when using clang18 from ports >> >>> On 10 Jan 2025, at 11:19, Dimitry Andric wrote: >>> >>> On 10 Jan 2025, at 10:22,

Re: libxkbcommon version-script detection

On 10 Jan 2025, at 12:20, Peter Blok wrote: > > Test works ok when using clang18 from ports > >> On 10 Jan 2025, at 11:19, Dimitry Andric wrote: >> >> On 10 Jan 2025, at 10:22, Peter Blok wrote: >>> >>> I have recompiled x11/libxkbcommon and i

Re: libxkbcommon version-script detection

On 10 Jan 2025, at 10:22, Peter Blok wrote: > > I have recompiled x11/libxkbcommon and it fails to detect if the > compiler/linker supports versioned symbols. As a result other code expecting > the versioned symbol to exist, fail to link. > > C compiler for the host machine: cc (clang 19.1.5 "

Re: What's the newest C++ standard that we can target?

On 8 Jan 2025, at 18:46, Alan Somers wrote: > > On Wed, Jan 8, 2025 at 10:44 AM Dimitry Andric wrote: >> >> On 8 Jan 2025, at 18:31, Alan Somers wrote: >>> >>> What is the newest C++ standard that we can target in src, and be >>> confident that

Re: What's the newest C++ standard that we can target?

On 8 Jan 2025, at 18:31, Alan Somers wrote: > > What is the newest C++ standard that we can target in src, and be > confident that it will compile on all targets? Can we use C++20? C++17 is probably the safest one, as C++20 support in libc++ 19 is mostly done, but not entirely complete: https:

Re: zpools no longer exist after boot

On 28 Nov 2024, at 14:05, Dennis Clarke wrote: > > This is a baffling problem wherein two zpools no longer exist after > boot. This is : > > titan# uname -apKU > FreeBSD titan 15.0-CURRENT FreeBSD 15.0-CURRENT #1 > main-n273749-4b65481ac68a-dirty: Wed Nov 20 15:08:52 GMT 2024 > root@titan:/usr

Re: port binary dumping core on recent head in poudriere [tmpfs corruptions involving blocks of zeros that should not be all zeros]

On 26 Nov 2024, at 13:32, Dimitry Andric wrote: > > On 26 Nov 2024, at 11:19, Dag-Erling Smørgrav wrote: >> >> Mark Millard writes: >>> From inside a bulk -i where I did a manual make command >>> after it built and installed libsass.so.1.0.0 . The

Re: port binary dumping core on recent head in poudriere [tmpfs corruptions involving blocks of zeros that should not be all zeros]

On 26 Nov 2024, at 11:19, Dag-Erling Smørgrav wrote: > > Mark Millard writes: >> From inside a bulk -i where I did a manual make command >> after it built and installed libsass.so.1.0.0 . The >> manual make produced a /wrkdirs/ : >> [...] >> So the original creation looks okay. But . . . >> [...

Re: port binary dumping core on recent head in poudriere

On 25 Nov 2024, at 23:12, Mark Millard wrote: > > On Nov 25, 2024, at 13:27, Guido Falsi wrote: > >> On 25/11/24 22:18, Dag-Erling Smørgrav wrote: >>> Mark Millard writes: >>>> Guido Falsi writes: >>>>> On 25/11/24 09:17, Dag-E

Re: port binary dumping core on recent head in poudriere

On 24 Nov 2024, at 18:07, Guido Falsi wrote: > > On 23/11/24 15:56, Guido Falsi wrote: >> On 23/11/24 15:34, Guido Falsi wrote: >>> On 21/11/24 18:33, Guido Falsi wrote: >>>> On 21/11/24 18:27, Dimitry Andric wrote: >>>>> On 21 Nov 2024, at 18:17

Re: port binary dumping core on recent head in poudriere

On 21 Nov 2024, at 18:17, Guido Falsi wrote: > > On 20/11/24 23:50, Guido Falsi wrote: >> On 20/11/24 22:14, Dimitry Andric wrote: >>> On 20 Nov 2024, at 18:32, Guido Falsi wrote: >>>> I've noticed that recently some ports are dumping core during b

Re: port binary dumping core on recent head in poudriere

On 20 Nov 2024, at 18:32, Guido Falsi wrote: > I've noticed that recently some ports are dumping core during builds of > dependencies in head in poudriere. > > I'm seeing this for example with sassc crashing while trying to build > x11-themes/greybird-theme. > > My first suspect was the llvm u

Re: Playing around with security hardening compiler flags

On 17 Nov 2024, at 16:30, Alexander Leidinger wrote: > > Hi, > > after reading > > https://security.googleblog.com/2024/11/retrofitting-spatial-safety-to-hundreds.html >https://libcxx.llvm.org/Hardening.html > > https://best.openssf.org/Compiler-Hardening-Guides/Compiler-Options-Hard

Re: llvm19 lld issue

On 14 Nov 2024, at 13:44, Michal Meloun wrote: > > While searching for the cause of armv7 kernel corruption after updating to > llvm19 lld, I came across an interesting problem. > > - The linker script does not list all generated sections. Specifically, the > data sections created by the linke

Re: speedup build time

The compiler and linker can run faster, if you disable their internal seatbelts. How much faster depends on the use case, but I have heard 5-10% being thrown around. The same holds for FreeBSD itself of course, though the performance difference there is probably different. In any case, if you d

Re: October 2024 stabilization week

On 22 Oct 2024, at 19:37, Gleb Smirnoff wrote: > > On Mon, Oct 21, 2024 at 01:00:31AM -0700, Gleb Smirnoff wrote: > T> This is an automated email to inform you that the October 2024 > stabilization week > T> started with FreeBSD/main at main-n273082-525a177c1657, which was tagged as > T> main-st

Re: install error during installworld

On 25 Sep 2024, at 12:32, Gordon Bergling wrote: > > I have a few Hyper-V based virtual machines, one acts as a build machine > and one as -CURRENT development machine / environment. > > The host crashed while I was executing an installworld installkernel make > target. > > When trying to resum

Re: change in /usr/bin/bc with CTRL-d no longer exit

On 15 Sep 2024, at 22:35, Herbert J. Skuhra wrote: > > On Sun, Sep 15, 2024 at 03:16:46PM -0500, Dan Mack wrote: >> On 14.1 and prior, a CTRL-d will exit a bc session. >> >> Today I noticed that on 3 different 15-CURRENT systems, it appears to be >> ignored. Works fine otherwise and I can exit

Re: Fall back to fast_float when C++ stdlib doesn't provide from_chars for floats

On 8 Aug 2024, at 19:56, Daniel Tameling wrote: > > On Tue, Aug 06, 2024 at 11:26:26AM +0100, Nuno Teixeira wrote: >> >> As I don't have skills to understand why this fix works, I'd like to have >> some expert opinion on this fix since I don't know if this will be >> supported in the future. >

Re: build of main broken? (ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_...' failed: symbol not defined)

On 24 May 2024, at 15:19, Matteo Riondato wrote: > > I’m trying to build 59aa64914aeb1b20d4fc39ead2ee159a1e5b from > main-62adeb92df, and got the error below. > > I cannot immediately trace it back to any recent commit, so I’m a bit > surprised by it. > > Any hint? > > --

Re: build failure affecting port: "error: reference to 'filesystem' is ambiguous"

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

Re: build failure affecting port: "error: reference to 'filesystem' is ambiguous"

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 main. > > Any help is welc

Re: llvm and Undefined symbols: ___truncsfbf2 problem

On 11 Apr 2024, at 15:07, Hiroo Ono wrote: > > Hello, > > I am trying to update the lang/julia port to 1.11.0 (currently still in beta > 1). > I seem to ran across this problem initially reported on MacOS. > https://github.com/JuliaLang/julia/issues/52067 > > The llvm team seems to have patche

Re: Problem with make installworld

On 21 Mar 2024, at 01:12, tue...@freebsd.org wrote: > >> On 21. Mar 2024, at 00:27, Dimitry Andric wrote: >> >> On 20 Mar 2024, at 21:44, tue...@freebsd.org wrote: >>> >>> I'm trying to run make buildworld / make installworld on a recent main

Re: Problem with make installworld

On 20 Mar 2024, at 21:44, tue...@freebsd.org wrote: > > I'm trying to run make buildworld / make installworld on a recent main branch > (some days old). > > The problem is related to lib/libc/tests/ssp/Makefile > which contains: > _libclang_rt_ubsan= > ${SYSROOT}${SANITIZER_LIBDIR}/libclang_

Re: sanitizers broken (was RE: libc/libsys split coming soon)

Can't we just add libsys.so to the /usr/lib/libc.so linker script? That would work for everything except static linking? -Dimitry > On 21 Feb 2024, at 21:00, Brooks Davis wrote: > > TL;DR: you can work around this by adding -lsys to the link line and I > aim to improve the situation soon. > >

Re: install: /usr/libexec/kgdb exists but is not a directory

On 17 Feb 2024, at 12:15, Dimitry Andric wrote: > > On 17 Feb 2024, at 01:02, Bjoern A. Zeeb > wrote: >> >> >> probably related to the 20201215 UPDATING note: >> >> during an update from last year's main to now I hit the following error: >>

Re: install: /usr/libexec/kgdb exists but is not a directory

On 17 Feb 2024, at 01:02, Bjoern A. Zeeb wrote: > > > probably related to the 20201215 UPDATING note: > > during an update from last year's main to now I hit the following error: > > install: /usr/libexec/kgdb exists but is not a directory > > Which is true as the old binary was still lingeri

Re: llvm ld vs binutils ld

On 27 Jan 2024, at 18:08, Steve Kargl wrote: > > In an attempt to cleanup a bit of src/lib/msun, I ran into > a small issue that I cannot explain at the moment. If I have > /usr/bin/ld in my path prior to /usr/local/bin/ld everything > works > > % which ld > /usr/bin/ld > % make clean && make c

Re: devel/nspr: Fails to build on 1500008 5f71f9636efa

The problem is really that our kernel headers (those under sys/) require C99. The only thing that https://cgit.freebsd.org/src/commit/?id=a8b70cf26030d68631200619bd1b0ad35b34b6b8 did was move two static inline functions from sys/netinet/tcp_var.h to sys/netinet/tcp.h, and it looks like the form

Re: symlink to /boot/loader.efi

ello Dimitry, > > For a moment I forgot that efiboot is a fat system... > I am inspired on what installworld does to kernel and kernel.old. > I was thinking in something like it but with efi boot, something automatic. > > Thanks! > > Dimitry Andric escreveu no dia quinta, 2

Re: symlink to /boot/loader.efi

On 21 Dec 2023, at 13:22, Nuno Teixeira wrote: > > On every current upgrade I update efi/freebsd/loader.efi (amd64) and > efi/boot/boota64 (aarch64) with new copies on /boot/loader.efi. > For safety reasons I always have a copy of last running loader by appending > "-old.efi" to loader or boota

Re: The ports quarterly tree 2023Q4 is borked for www/firefox

On 18 Dec 2023, at 13:59, Dennis Clarke wrote: > > > I do not know where else to post this. Seems that a bug report about the > problem does not mean much : > > > Bug 275814 - www/firefox has the wrong version in the Makefile > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=275814 Should b

Re: make installworld fails because /usr/include/c++/v1/__tuple is a file

On 13 Dec 2023, at 19:07, John Baldwin wrote: > > On 12/10/23 8:43 AM, Dimitry Andric wrote: >> On 10 Dec 2023, at 15:11, Herbert J. Skuhra wrote: >>> >>> On Sun, Dec 10, 2023 at 01:22:38PM +, John F Carr wrote: >>>> On arm64 runni

Re: compile 13.2p8 on a recent current fails: compiler issue ?

On 13 Dec 2023, at 13:08, henry vogt wrote: > > attempt to compile 13.2p8 on a recent current fails: compiler issue ? > > ... > > ===> usr.sbin/zic (obj,all,install) > Building /usr/obj/usr/src/13.2/amd64.amd64/tmp/obj-tools/usr.sbin/zic/zic.o > --- zic.o --- > /usr/src/13.2/contrib/tzcode/zic.

Re: upgrade failure

I think you are now left with a half-installed libc++ from the previous broken installworld. That is not likely to work correctly. Probably the way forward is to restore your /usr/include directory from a backup, and do the buildworld again after that. Alternatively, buildworld on another (non-

Re: make installworld fails because /usr/include/c++/v1/__tuple is a file

the file and try again, or is there a more elegant fix? >> >> The word "tuple" does not appear in UPDATING. > > 'make delete-old' should have removed this file. > > bdd1243df58e6 (Dimitry Andric 2023-04-14 23:41:27 +0200 965) > OLD_FILES+=usr/i

Re: aarch64 and armv6 vs. armv7 support: armv6 is not supported, despite what "man arch" reports

On 7 Dec 2023, at 05:31, Mark Millard wrote: > > man arch reports: > > QUOTE > Some machines support more than one FreeBSD ABI. Typically these are > 64-bit machines, where the “native” LP64 execution environment is > accompanied by the “legacy” ILP32 environment, which was the hist

Re: make installworld filed with "Required library libdialog.so.9 not found"

On 20 Sep 2023, at 15:02, KIRIYAMA Kazuhiko wrote: > > On Wed, 20 Sep 2023 15:56:28 +0900, > Dimitry Andric wrote: ... > Fortunately old binaries exist and `cp > /past_created/usr/src/amd64.amd64/tmp/usr/lib/libdialog.so.9 > /usr/lib' then go forward but stop

Re: make installworld filed with "Required library libdialog.so.9 not found"

On 20 Sep 2023, at 04:47, KIRIYAMA Kazuhiko wrote: > > I'm updating 15.0-CURRENT (main-n265415-b2bd87bb01a9) from > 14.0-CURRENT, but make installworld filed with "Required > library libdialog.so.9 not found" as follows: > > root@vm:/usr/src # make installworld > make[1] warning: /usr/src/: Read

Re: user problems when upgrading to v15

On 1 Sep 2023, at 03:42, brian whalen wrote: > > Repeating the entire process: > > I created a 13.2 vm with 6 cores and 8GB of ram. > > Ran freebsd-update fetch and install. > > Ran pkg install git bash ccache open-vm-tools-nox11 > > Used git clone to get current and ports source files. > >

Re: ZFS deadlock in 14: without ZIL

On 19 Aug 2023, at 09:36, Graham Perrin wrote: > > On 19/08/2023 00:03, Mark Millard wrote: >> I believe the below quoted messages were reports of deadlocks >> based on after the following 2 MFV being in place in their >> environments: >> >> Thu, 10 Aug 2023 >> . . . >> • git: cd25b0f740f8 -

Re: Jail compile error on CURRENT?

On 7 Aug 2023, at 04:50, Yoshihiro Ota wrote: > > Am I the only one seeing this error? > I'm on 12.4-RELEASE amd64 and building CURRENT as of now. > > jaillex.c:2228:43: error: unused parameter 'yyscanner' > [-Werror,-Wunused-parameter] > void *yyalloc (yy_size_t size , yyscan_t yyscanner) >

Re: HST time zone

On 25 Jul 2023, at 22:26, David Cornejo wrote: > > One thing that has bothered me for a long time is that the Pacific/Honolulu > timezone is found under the America -- North and South/United States of > America/Hawaii in tzsetup. Politics of Hawaiian Sovereignty aside, every > other system I r

Re: __cxa_thread_call_dtors: dtr 0x........ from unloaded dso, skipping

> On 29 Jun 2023, at 13:52, Willem Jan Withagen wrote: > > On 29-6-2023 12:37, Dimitry Andric wrote: >> On 29 Jun 2023, at 12:25, Willem Jan Withagen wrote: >>> On 26-6-2023 17:38, Dimitry Andric wrote: >>>> On 26 Jun 2023, at 17:29, Bjoern A. Zeeb &

Re: __cxa_thread_call_dtors: dtr 0x........ from unloaded dso, skipping

On 29 Jun 2023, at 12:25, Willem Jan Withagen wrote: > > On 26-6-2023 17:38, Dimitry Andric wrote: >> On 26 Jun 2023, at 17:29, Bjoern A. Zeeb >> wrote: >>> On Mon, 26 Jun 2023, Dimitry Andric wrote: >>> >>>> On 26 Jun 2023, at 17:00, Bjoern

Re: __cxa_thread_call_dtors: dtr 0x........ from unloaded dso, skipping

On 26 Jun 2023, at 17:29, Bjoern A. Zeeb wrote: > > On Mon, 26 Jun 2023, Dimitry Andric wrote: > >> On 26 Jun 2023, at 17:00, Bjoern A. Zeeb >> wrote: >>> >>> while building world and current I see a lot of: >>> >>> __cxa_th

Re: __cxa_thread_call_dtors: dtr 0x........ from unloaded dso, skipping

On 26 Jun 2023, at 17:00, Bjoern A. Zeeb wrote: > > while building world and current I see a lot of: > > __cxa_thread_call_dtors: dtr 0x.. from unloaded dso, skipping > > Can anyone shed light on that? You need (thanks to Kostik): https://cgit.freebsd.org/src/commit/?id=42ceab3ea1a997db93b

Re: OpenSSL 3.0 is in the tree

On 24 Jun 2023, at 16:22, Ed Maste wrote: > > Last night I merged OpenSSL 3.0 to main. This, along with the update > to Clang 16 and other recent changes may result in some challenges > over the next few days or weeks for folks following -CURRENT, such as > ports that need to be updated or unanti

Re: Using etcupdate resolve, was Re: Surprise null root password

On 15 Jun 2023, at 19:26, bob prohaska wrote: > > Here's an example of the puzzles faced when using etcupdate > that have so far proved baffling: > > On running etcupdate resolve, the system reports > > Resolving conflict in '/etc/mtree/BSD.tests.dist': > Select: (p) postpone, (df) diff-full, (

Re: "make hierarchy" from main tree breaks c++ headers on older branches with unclear errors if "make install world" is interrupted

On 31 May 2023, at 01:07, Enji Cooper wrote: > >> On May 28, 2023, at 3:53 AM, Dimitry Andric wrote: >> On 28 May 2023, at 07:18, Enji Cooper wrote: >>> >>> I just tried to run “make hierarchy” from a main tree on a 13.2-RELEASE >>> system, and do

Re: "make hierarchy" from main tree breaks c++ headers on older branches with unclear errors if "make install world" is interrupted

On 28 May 2023, at 07:18, Enji Cooper wrote: > > I just tried to run “make hierarchy” from a main tree on a 13.2-RELEASE > system, and doing so completely broke my headers. > It took me about 30 minutes to figure out what happened… > /usr/include/c++/v1/__string was a header, whereas on :main i

Re: Build failure in usr.sbin/bhyvectl; sources at main-n263112-ad513b4dba3e

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

Re: Delay in 14.0-RELEASE cycle and blocking items

On 3 May 2023, at 09:53, Alexey Dokuchaev wrote: > > On Mon, May 01, 2023 at 06:14:49PM +, Glen Barber wrote: >> ... >> There is no feasible way we are going to make the branch point of >> stable/14 in time, with that scheduled for May 12, 2023 with the above >> points. That said, this is no

Re: find(1): I18N gone wild ?

On 21 Apr 2023, at 12:01, Ronald Klop wrote: > Van: Poul-Henning Kamp > Datum: maandag, 17 april 2023 23:06 > Aan: curr...@freebsd.org > Onderwerp: find(1): I18N gone wild ? > This surprised me: > > # mkdir /tmp/P > # cd /tmp/P > # touch FOO > # touch bar > # env LANG=C.UTF-8

Re: aarch64: lang/gcc1* build regression between Mar-28 and Apr-8

On 13 Apr 2023, at 23:42, Dima Panov wrote: > Somethings changed in main branch between Mar, 28 and Apr, 8 which causes > permanent build error for lang/gcc1[012] on aarch64 (exactly VMWare container > on M1Pro mac) > > during RTL pass: sched1 > gimple-match.cc: In function 'bool gimple_nop_ato

Re: NanoBSD: CURRENT unable to compile 13-STABLE : error: a function definition without a prototype is deprecated ... in C

On 8 Mar 2023, at 11:19, FreeBSD User wrote: ... > But I don't understand why the make environment is trying to compile a piece > of code that is > disabled via "nodevice" as shown in my initial report herein: > > [...] > src/sys/dev/an/if_an_pci.c:143:1: error: a function definition without a

Re: NanoBSD: CURRENT unable to compile 13-STABLE : error: a function definition without a prototype is deprecated ... in C

On 2 Mar 2023, at 06:41, FreeBSD User wrote: > > Am Mon, 27 Feb 2023 23:46:21 +0100 > Dimitry Andric schrieb: ... > > I tried to find some documentation on my CURRENT host regarding > "WITH_SYSTEM_COMPILER". None > found via man src.conf, nor via make make.c

Re: NanoBSD: CURRENT unable to compile 13-STABLE : error: a function definition without a prototype is deprecated ... in C

On 27 Feb 2023, at 22:23, Paul Mather wrote: > > On Feb 27, 2023, at 2:57 PM, Dimitry Andric wrote: > >> On 27 Feb 2023, at 19:19, FreeBSD User wrote: >>> >>> Running recent CURRENT as host (FreeBSD 14.0-CURRENT #23 >>> main-n261147-b8bb73ab724b: Su

Re: NanoBSD: CURRENT unable to compile 13-STABLE : error: a function definition without a prototype is deprecated ... in C

On 27 Feb 2023, at 19:19, FreeBSD User wrote: > > Running recent CURRENT as host (FreeBSD 14.0-CURRENT #23 > main-n261147-b8bb73ab724b: Sun Feb 26 > 17:39:38 CET 2023 amd64), and nanoBSD (recent 13-STABLE, git stable/13). > > Building an appliance based on 13-STABLE sources, a customized kernel

Re: core dump in ld during buildworld

On 19 Feb 2023, at 06:15, Steve Kargl wrote: > > On Sat, Feb 18, 2023 at 04:57:45PM -0800, Steve Kargl wrote: >>> >>> At that point it is still using the system compiler and linker, and it >>> seems that the latter is lld. Do you know which version it is? >>> >> >> Good question. Unfortunate

Re: core dump in ld during buildworld

On 19 Feb 2023, at 01:33, Steve Kargl wrote: > > During biuldworld, > > ==> usr.bin/nm (obj,all,install) > cc -O2 -pipe -g -fno-common -I/usr/src/contrib/elftoolchain/libelftc > -I/usr/src/contrib/elftoolchain/common -std=gnu99 -Wno-format-zero-length > -Wsystem-headers -Wall -Wno-format-y2k -

Re: buildworld failed after deleting /usr/obj

On 23 Jan 2023, at 04:05, qroxana wrote: > > It seems ${MAKEOBJDIR} was not created for usr.bin/clang/llvm-objcopy. > > --- all_subdir_usr.bin --- > --- objwarn --- > Warning: Object directory not changed from original > /usr/src/usr.bin/clang/llvm-objcopy This is usually an indication that yo

Re: Did clang 14 lose some intrinsics support?

On 25 Sep 2022, at 23:38, Christian Weisgerber wrote: > > Dimitry Andric: > >>> See https://github.com/llvm/llvm-project/commit/e5147f82e1cb >>> >>> - Instead of __builtin_ia32_pabsd128 maybe use _mm_abs_epi32 >>> - Instead of __builtin_ia32_p

Re: Did clang 14 lose some intrinsics support?

On 25 Sep 2022, at 21:02, Jan Beich wrote: > > Christian Weisgerber writes: > >> Did we lose support for SSSE3 and AVX2 intrinsics on amd64 with >> clang 14? > > __builtin_* appear unstable unlike _mm* intrinsics. Clang 15 seems > to hide more but I'm not sure about the cause (need bisecting).

Re: About zfs upgrade

On 16 Jul 2022, at 18:09, Nuno Teixeira wrote: > I'm about to upgrade zfs pool and I need to know the command to update boot > code on my efi config: > --- > gpart show > =>40 2000409184 nvd0 GPT (954G) > 40 532480 1 efi (260M) > 5325202008-

Re: buildworld fail: ld: error: undefined symbol: test_no_kevents

Looks like it might be using an old version of tests/sys/kqueue/libkqueue/common.h, after https://cgit.freebsd.org/src/commit/?id=c728c56c870abe230e45cee5c477f0d890ebacef ? Without seeing how the .o files have been compiled, specifically with which -I flags, it is impossible to see what is goi

Re: Bulld failure of editors/libreoffoce only on main (aka -current)

On 23 May 2022, at 17:53, Tomoaki AOKI wrote: > > After some discussion with Mark Millard on Bug 263976 and some tests, > I've changed the subject of it to "editors/libreoffice: Fails to build > if LLVM_DEFAULT=90 (default) and LTO=on (non-default)". > > With LTO option enabled, port default dev

Re: Buildworld fails with external GCC toolchain

On 11 Feb 2022, at 21:07, Yasuhiro Kimura wrote: > > I'm tring to update devel/binutils port to 2.38. When it was updated > to 2.37.1, there was a suggestion that it should also be checked if > building base system with GCC succeeds as binutils is a part of > external GCC toolchain. So I'd like t

Re: git: 6b1c5775d1c2 - main - Move libc++ from /usr/lib to /lib

On 29 Dec 2021, at 22:40, Mark Millard via dev-commits-src-main wrote: > > [Resending with dev-commits-src-m...@freebsd.org CC'd.] > > On 2021-Dec-29, at 13:38, Mark Millard wrote: > > Building 33812d60b960 ( so after 6b1c5775d1c2 ) and installing > and rebooting did not put in place a /lib/l

Re: CURRENT: llvm13 seem to miscompile dns/bind916 (9.16.23)

On 15 Dec 2021, at 18:44, FreeBSD User wrote: > > On Fri, 10 Dec 2021 19:41:07 +1030 > Daniel O'Connor via freebsd-current wrote: >>> On 25 Nov 2021, at 18:50, FreeBSD User wrote: ... > >>> Since then named is crashing with a mysterious segmentation fault (see PR >>> 259921, >>> https://bugs.

Re: failure of pructl (atexit/_Block_copy/--no-allow-shlib-undefined)

On 2 Dec 2021, at 06:42, Kyle Evans wrote: > On Wed, Dec 1, 2021 at 8:05 PM John-Mark Gurney wrote: >> >> Hello, >> >> It seems like the recent changes to make --no-allow-shlib-undefined >> broke pructl. >> >> lib/libc/stdlib/atexit.c uses a weak _Block_copy symbol, but >> pructl does not use

Re: failure of pructl (atexit/_Block_copy/--no-allow-shlib-undefined)

On 2 Dec 2021, at 06:42, Kyle Evans wrote: > > On Wed, Dec 1, 2021 at 8:05 PM John-Mark Gurney wrote: >> >> Hello, >> >> It seems like the recent changes to make --no-allow-shlib-undefined >> broke pructl. >> >> lib/libc/stdlib/atexit.c uses a weak _Block_copy symbol, but >> pructl does not u

Re: Incompatible change in LLD13 causing link errors?

On 17 Nov 2021, at 21:07, Stefan Esser wrote: > > I have just received pkg-fallout for a port that has not been touched > for several months, specifically lang/silq. > > ld.lld: error: undefined hidden symbol: __start___minfo referenced by terminal.d silq.o:(ldc.register_d

Re: armv7 targeting (on aarch64, via poudriere-devel): system's clang 13 rejected building devel/lllvm13

On 15 Nov 2021, at 19:14, Mark Millard via arm wrote: > > There error was: > > error: non-constant-expression cannot be narrowed from type 'long long' to > 'std::size_t' (aka 'unsi > gned int') in initializer list [-Wc++11-narrowing] > std::size_t resultBytes{size * elementBytes}; >

HEADS UP: intent to merge clang/llvm 13.0.0 the coming weekend

Hi, This is a heads-up so that you are aware I'm intending to merge clang/llvm 13.0.0 the coming weekend, e.g. somewhere between Sat 2021-11-13 and Sun 2021-11-14. The source of the merge will be , which I regularly sync up with our

Re: WHY? commit ac76bc1145dd7f4476e5d982ce8f355f71015713

On 5 Nov 2021, at 21:13, Steve Kargl wrote: > > Why was this committed? > > commit ac76bc1145dd7f4476e5d982ce8f355f71015713 > Author: Dimitry Andric > Date: Tue Feb 9 22:06:51 2021 +0100 > >Fix lib/msun's ctrig_test/test_inf_inputs test case with clang >=

Re: poudriere jail with todays current: Install fail?

On 20 Oct 2021, at 13:51, Larry Rosenman wrote: > > On 10/20/2021 6:41 am, Dimitry Andric wrote: >> On 20 Oct 2021, at 03:50, Larry Rosenman wrote: >>> Anyone else having poudriere jail -u or jail -c fail in the installworld? >>> log: >>> https://www.

Re: poudriere jail with todays current: Install fail?

On 20 Oct 2021, at 03:50, Larry Rosenman wrote: > Anyone else having poudriere jail -u or jail -c fail in the installworld? > > log: > https://www.lerctr.org/~ler/jail-install.log The actual error is pretty far from the bottom of that log: --- realinstall_subdir_usr.sbin/lpr/chkprintcap --- ins

Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm

On 9 Oct 2021, at 15:40, Warner Losh wrote: > > On Sat, Oct 9, 2021, 5:59 AM Dimitry Andric wrote: > On 9 Oct 2021, at 13:37, Dimitry Andric wrote: > > > > On 9 Oct 2021, at 09:46, FreeBSD User wrote: > >> > >> On recent CURRENT (FreeBSD 14.0-CURRENT #2

Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm

On 9 Oct 2021, at 13:37, Dimitry Andric wrote: > > On 9 Oct 2021, at 09:46, FreeBSD User wrote: >> >> On recent CURRENT (FreeBSD 14.0-CURRENT #2 main-n249971-0525ece3554e: >> Fri Oct 8 15:17:34 CEST 2021 amd64) building of an 13-STABLE based >> appliance failed v

Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm

On 9 Oct 2021, at 09:46, FreeBSD User wrote: > > On recent CURRENT (FreeBSD 14.0-CURRENT #2 main-n249971-0525ece3554e: > Fri Oct 8 15:17:34 CEST 2021 amd64) building of an 13-STABLE based > appliance failed very early in the build process of the 13-STABLE > sources as shown below. 13-STABLE is m

Re: CURRENT: acpi_wakecode.S error: unknown -Werror warning specifier: '-Wno-error-tautological-compare'

On 22 Jun 2021, at 20:24, John Baldwin wrote: > > On 6/22/21 11:13 AM, O. Hartmann wrote: >> Hello, >> on a recent CURRENT (FreeBSD 14.0-CURRENT #6 main-n247512-e3be51b2bc7c: Tue >> Jun 22 15:31:03 >> CEST 2021 amd64) we build a 13-STABLE based NanoBSD from a dedicated source >> tree for a smal

Re: git: 790a6be5a169 - main - Export various 128 bit long double functions from libgcc_s.so.1

On 14 Jun 2021, at 22:38, Mark Millard wrote: > > Dimitry Andric dim at FreeBSD.org wrote on > Mon Jun 14 19:17:40 UTC 2021 : > >> The branch main has been updated by dim: >> >> URL: >> https://cgit.FreeBSD.org/src/commit/?id=790a6be5a1699291c6da87

Re: Panics in recent NFS server

gt;> I'll look at this later. >> >> Well let me rephrase. While the panic was added in said commit, I >> suspect the bug is on nfs side -- it has its own namei variant which I >> suspect is managing ni_pathlen in a manner different than the >> original, it jus

Panics in recent NFS server

Hi, I recently upgraded a -CURRENT NFS server from 2021-05-12 to today (2021-05-31), and when the first NFS client attempted to connect, I got this panic: panic: lookup: expected nul at 0xf800104b3002; string [dim] cpuid = 0 time = 1622463863 KDB: stack backtrace: db_trace_self_wrapper() a

Re: Undefined compiler behaviour or a compiler bug?

On 29 Apr 2021, at 23:11, Hans Petter Selasky wrote: > > On 4/29/21 11:06 PM, Hans Petter Selasky wrote: >> Hi, >> Can someone please explain what C-compiler flag I'm missing, to make this >> simple C-program terminate? >> I have a function _abs() which at some point is equal to one, but the >>

Re: base compiler & build options

On 22 Apr 2021, at 13:20, Filippo Moretti via freebsd-current wrote: > > I run FreeBSD STING 14.0-CURRENT FreeBSD 14.0-CURRENT #24 > main-n246214-78ffcb86d98: Tue Apr 20 17:51:50 CEST 2021 > root@STING:/usr/obj/usr/src/amd64.amd64/sys/STING amd64 > > will llvm12 be merged on main or shou

Re: Problem compiling gcc10

On 6 Mar 2021, at 11:19, Filippo Moretti wrote: > > This is the output from MAKE_JOBS_UNSAFE=yes > > checking whether the C compiler works... yes > checking for C compiler default output file name... a.out > checking for suffix of executables... > checking whether we are cross compiling... confi

Re: Problem compiling gcc10

On 5 Mar 2021, at 18:19, Filippo Moretti via freebsd-current wrote: > > The following is the error while compiling on: > [root@sting /usr/ports]# uname -aFreeBSD sting 14.0-CURRENT FreeBSD > 14.0-CURRENT #32 main-n245104-dfff1de729b: Fri Feb 26 12:08:40 CET 2021 > root@sting:/usr/obj/usr/src/a

Re: HEADS-UP: PIE enabled by default on main

On 26 Feb 2021, at 03:22, Ed Maste wrote: > > On Thu, 25 Feb 2021 at 19:23, John Kennedy wrote: >> >> Not sure if Ed Maste just wants to make sure that all the executables >> are rebuilt as PIE (vs hit-and-miss) or there is a sneaker corner-case that >> he knows about. > > The issue is that w

Re: pkg vs uname troubles after upgrade to 14 (lld not rebuilt issue? (X_)LINKER_FREEBSD_VERSION still 13 based?)

On 17 Feb 2021, at 04:28, Mark Millard via freebsd-current wrote: > > On 2021-Feb-16, at 15:37, Mark Millard wrote: >> On 2021-Feb-16, at 11:49, Brandon Bergren wrote: >>> It looks like there were recently some fixes to release.sh, that just got >>> backported to 13. I wonder if the problem i

Re: [PACTH,libm] hypothl(x) mishandles subnormal numbers.

> On 10 Feb 2021, at 00:15, Steve Kargl > wrote: > > On Sat, Feb 06, 2021 at 10:32:33PM +0100, Dimitry Andric wrote: >> On 6 Feb 2021, at 22:04, Steve Kargl >> wrote: >>> >>> On Sat, Feb 06, 2021 at 12:39:29PM -0800, Steve Kargl wrote: >>>

Re: [PATCH, LIBM] powf is wrong with x near 1 and |y| >> 1

On 7 Feb 2021, at 23:53, Steve Kargl wrote: > > See the last few comments here: > > https://github.com/JuliaMath/openlibm/issues/211 Thanks Steve. Committed here: https://cgit.freebsd.org/src/commit/?id=93fc67896550548f91b307dbe3053f11db5d4a8a -Dimitry signature.asc Description: Message si

  1   2   3   4   5   6   7   8   9   >