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"

m/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, Nuno Teixeira wr

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

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

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 rec

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= >

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

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

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

Re: symlink to /boot/loader.efi

o 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, 21/12/2023 à(s)

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

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

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 ru

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 --- >

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

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

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/include/c++/

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

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 stopped a

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/:

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

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):

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

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

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

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

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

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

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

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-b8bb73ab72

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

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

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

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

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

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

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

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, >>>

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

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

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

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 >= 10 &

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

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 ---

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

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

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

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 just happens to not panic on

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()

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

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...

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 >

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

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

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

Re: hypothl(x) mishandles subnormal numbers.

On 6 Feb 2021, at 22:04, Steve Kargl wrote: > > On Sat, Feb 06, 2021 at 12:39:29PM -0800, Steve Kargl wrote: >> I've long forgotten by freebsd bugzilla password. >> So, if someone would like to submit a bug report, >> here's a test program. >> > Forgot to include that issue was identified from

Re: kldxref: /boot/kernel/kernel: too many segments

On 6 Jan 2021, at 08:14, Matthias Apitz wrote: > > El día martes, enero 05, 2021 a las 01:11:14p. m. +0100, Herbert J. Skuhra > escribió: > >> On Tue, Jan 05, 2021 at 01:01:33PM +0100, Matthias Apitz wrote: >>> >>> Hello, >>> >>> On an amd64 system r314251 a world and kernel built fine from

Re: possible usb3-connected hard drive spin down causing lag

On 26 Nov 2020, at 19:21, Gary Jennejohn wrote: > > On Thu, 26 Nov 2020 10:44:19 -0700 > Warner Losh wrote: ... >>> Example: >>> >>> /sbin/camcontrol standby /dev/da2 -v -t 1800 >> >> >> Perfect! I've not had to deal with sata disks that did this since the >> ataidle days. I looked in

Re: possible usb3-connected hard drive spin down causing lag

On 26 Nov 2020, at 01:10, tech-lists wrote: > > I have a usb3-connected harddrive. dmesg shows this: > [...] > da0: Fixed Direct Access SPC-4 SCSI device > [...] > > running current-r367806-arm64 > > I think it might be auto-spinning-down or auto-sleeping. It's > making initial interaction

Re: buildworld: lib/libc: install: short write to libc.so.7.debug: [_libinstall] Error code 71

On 22 Nov 2020, at 08:06, Graham Perrin wrote: > > On 20/11/2020 09:57, Graham Perrin wrote: >> On 16/11/2020 09:27, Graham Perrin wrote: >>> Attempting to build r367615 on Friday 13th: >>> >>> … >>> >>> ===> lib/libprocstat/zfs (install) >>> install -U -C -o root -g wheel -m 444 >>>

Re: mips32 + gcc9 -- still broken

Sorry, i hadn't picked up on this thread at all. What is the concrete patch you are proposing? Is is in Phabricator somewhere? (Note that when building with gcc, we should really just automatically add -latomic, to get rid of these errors.) -Dimitry > On 5 Oct 2020, at 05:40, Adrian Chadd

Re: clang build buggy code with certain CPUTYPE setting

On 26 Sep 2020, at 13:40, Marek Zarychta wrote: > > I have done a few builds of CURRENT in a row one or two weeks apart. The > builds with CPUTYPE?=amdfam10 set produce buggy code, for example while > running mergemaster I get this error: > > PLEASE submit a bug report to

Re: compiling with ports llvm11 breaks on mman.h: struct shm_larg epage_conf

On 13 Sep 2020, at 20:56, Dimitry Andric wrote: > > On 12 Sep 2020, at 23:00, Ronald Klop wrote: >> >> On Sat, 12 Sep 2020 18:28:03 +0200, Dimitry Andric wrote: >>> On 12 Sep 2020, at 17:43, Ronald Klop wrote: >>>> >>>> Because I'm tire

Re: compiling with ports llvm11 breaks on mman.h: struct shm_larg epage_conf

On 12 Sep 2020, at 23:00, Ronald Klop wrote: > > On Sat, 12 Sep 2020 18:28:03 +0200, Dimitry Andric wrote: >> On 12 Sep 2020, at 17:43, Ronald Klop wrote: >>> >>> Because I'm tired of hours of compilation of llvm/clang I'm testing >>> c

Re: compiling with ports llvm11 breaks on mman.h: struct shm_larg epage_conf

On 12 Sep 2020, at 17:43, Ronald Klop wrote: > > Because I'm tired of hours of compilation of llvm/clang I'm testing compiling > FreeBSD with llvm11 from a pkg. > > Setup a jail with 13-CURRENT. Compilation of the installed version went fine. > Today I svn up'd and compiled and compilation

Re: clang miscompiles OpenLibm on i686-*-freebsd

On 8 Sep 2020, at 19:47, Steve Kargl wrote: > > On Mon, Sep 07, 2020 at 07:55:13PM -0700, Steve Kargl wrote: >> On Mon, Sep 07, 2020 at 07:10:02PM -0700, Steve Kargl wrote: >>> >>> Interval tested for exp2f: [1,8] >>> ulp <= 0.5: 0.056% 14072 | 0.056% 14072 >>> 0.5 < ulp <

Re: Plans for git (was: Please check the current beta git conversions)

On 2 Sep 2020, at 17:18, Ed Maste wrote: > > On Wed, 2 Sep 2020 at 07:51, Mathieu Arnold wrote: >> >>> Git also supports sha-256 soon now, adoption should >>> be researched from various online article series and >>> work product before committing plans... >>> https://lwn.net/Articles/823352/

Re: ld: error: duplicate symbol:

On 17 Aug 2020, at 15:42, O. Hartmann wrote: > > On CURRENT 9not necessarily most recent with LLVM11, but since noon of today > it > is FreeBSD 13.0-CURRENT #15 r364297: Mon Aug 17 14:39:06 CEST 2020 amd64) I'm > faced with some very sticky and nasty micompilations in several essential > ports,

Re: "make buildworld" fails for r360785?

On 9 May 2020, at 05:10, Robert Huff wrote: > > Chris writes: >>> "make buildowrld" fails with: ... /usr/src/contrib/llvm-project/clang/lib/Basic/SourceManager.cpp:1228:10: fatal error: 'emmintrin.h' file not found #include ^ ... > In file included

Re: kernel build failed

On 29 Mar 2020, at 13:02, Alexandr Krivulya wrote: > > 28.03.20 18:32, Dimitry Andric пишет: >> On 28 Mar 2020, at 13:48, Alexandr Krivulya wrote: ... >> This typically happens if you don't run "make buildworld", or at least >> "make kernel-toolchain"

Re: kernel build failed

On 28 Mar 2020, at 13:48, Alexandr Krivulya wrote: > > 28.03.20 14:35, David Wolfskill пишет: >> On Sat, Mar 28, 2020 at 02:01:39PM +0200, Alexandr Krivulya wrote: >>> Hello, >>> on latest CURRENT kernel fails to build: >>> >>> ===> aesni (all) >>> [Creating objdir >>>

Re: cannot build 12.1-RELEASE on latest current-snapshot

On 21 Mar 2020, at 16:52, h v wrote: > >> On 20.03.20 18:20, Warner Losh wrote: >>> >>> ... >>> No. This was an error I committed. Update and try again. I had one >>> too many changes in the tree I pushed this morning. >>> >>> Warner >> >> >> Unfortunately not.. im now @13.0-CURRENT r359179

Re: cannot build 12.1-RELEASE on latest current-snapshot

On 20 Mar 2020, at 10:55, h v wrote: > > buildworld for 12.1-RELEASE fails on recent current.. in stage 3: cross > tools (see below) > > Did i miss newer Options/ Parameters (i checked UPDATING without > relevant changes) > > i'm also not attemting a cross build, simply compiling on amd64 for

Re: Build failed compiling ittnotify_static.pico

On 14 Mar 2020, at 17:24, Roman Bogorodskiy wrote: > > Dimitry Andric wrote: >> On 13 Mar 2020, at 23:58, Waitman Gobble wrote: >>> >>> On 2020-03-13 17:49, Waitman Gobble wrote: >>>> On 2020-03-13 16:57, Bob Willcox wrote: >> ... >>>

Re: Build failed compiling ittnotify_static.pico

On 14 Mar 2020, at 04:53, Masachika ISHIZUKA wrote: > >>> cc: error: no such file or directory: >>> '/usr/src/contrib/llvm-project/openmp/runtime/src/thirdparty/ittnotify/ittnotify_static.c' >>> cc: error: no input files >>> *** [ittnotify_static.pico] Error code 1 >> >> 'make

Re: Build failed compiling ittnotify_static.pico

On 13 Mar 2020, at 23:58, Waitman Gobble wrote: > > On 2020-03-13 17:49, Waitman Gobble wrote: >> On 2020-03-13 16:57, Bob Willcox wrote: ... >>> cc: error: no such file or directory: >>> '/usr/src/contrib/llvm-project/openmp/runtime/src/thirdparty/ittnotify/ittnotify_static.c' >>> cc: error: no

Re: emulators/qemu-user-static linker error on 13-CURRENT r358890

On 12 Mar 2020, at 15:35, Warner Losh wrote: > > On Thu, Mar 12, 2020 at 8:24 AM Glen Barber wrote: >> 13-CURRENT aarch64 GENERIC builds failed this week due to the dependent >> port emulators/qemu-user-static failing to build, which is used by the >> targets that create the cloud provider

Re: llvm 10 libomp build error

On 12 Mar 2020, at 11:38, Kristof Provost wrote: > > On 12 Mar 2020, at 16:58, Ronald Klop wrote: ... >> cc: error: no such file or directory: >> '/data/src/freebsd-current/contrib/llvm-pr >> oject/openmp/runtime/src/thirdparty/ittnotify/ittnotify_static.c' >> cc: error: no input files >> ***

Heads up: x86 boot components link changes

Hi, In base r358643 I committed a few changes in stand/i386, which cause most of the x86 boot components (e.g /boot/boot, /boot/loader and so on) to link using a linker script. This is in preparation of the clang and lld 10.0.0 import. Even though I tested that the resulting binaries appear to

Re: FATAL kernel too old

On 2020-02-13 18:56, Matthias Apitz wrote: I'm compiling ports with poudriere on a very recent kernel and I'm getting the attached errors. What does this mean? Thanks. matthias FreeBSD 13.0-CURRENT (GENERIC) #2 r357756: Tue Feb 11 18:52:09 CET 2020 [01:28:59] [04] [00:01:01] Finished

  1   2   3   4   5   6   7   8   9   >