From Newsgroup: muc.lists.freebsd.stable

Hi,
I have multiple systems which I update from the same 14-stable source with latest commit 465c30c4f202b02cd9cb12f12d9ea856c84c5203 of November 23.
I updated one system with installkernel installworld over NFS without problems. Next I did the build system that was having the src and obj, but it stopped with the installworld. Retrying the installworld resulted with the ld-elf.so.1: /usr/bin/cc: Undefined symbol rCLLLVMInitializeAArch64TargetInforCY message.
All systems are Intel or Amd, so IrCOm puzzled why the above symbol is needed. The only thing I can think of is that the build system builds all target compilers. The sucessfully installed system has a different src.conf without that option.
What is wrong here? The update sequence I use is always the same.
Peter
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.stable

On 24 Nov 2025, at 09:43, Peter Blok <pblok@bsd4all.org> wrote:

I have multiple systems which I update from the same 14-stable source with latest commit 465c30c4f202b02cd9cb12f12d9ea856c84c5203 of November 23.

I updated one system with installkernel installworld over NFS without problems. Next I did the build system that was having the src and obj, but it stopped with the installworld. Retrying the installworld resulted with the ld-elf.so.1: /usr/bin/cc: Undefined symbol rCLLLVMInitializeAArch64TargetInforCY message.

All systems are Intel or Amd, so IrCOm puzzled why the above symbol is needed. The only thing I can think of is that the build system builds all target compilers. The sucessfully installed system has a different src.conf without that option.

What is wrong here? The update sequence I use is always the same.

I think this is because your systems have been built with different src.conf configurations. These days /usr/bin/cc links to /usr/lib/libprivatellvm.so.19, so if you are installing world from a machine where src.conf options were different (in particular the WITHOUT_LLVM_TARGET_xxx options), there can be a mismatch between the symbols expected by the cc binary and the libprivatellvm.so.19 library.
During installworld there is a moment where the libprivatellvm.so.19 library is installed, and where /usr/bin/cc is not yet updated. Due to our build system running recursive make, and some of those Makefiles invoking /usr/bin/cc, you can run into this issue.
-Dimitry
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.stable

Thanks for the explanation. This was a good lesson for me to setup an alternate boot environment with beadm.
I checked and the system with the problem is the build machine which has the same src.conf for building and installing. So it must be related to the aborted install where /usr/lib was updated and /usr/bin was not.
Although I use the same source for all systems, I did a better job than I initially mentioned. All systems have the same src.conf when building nd installing.
Peter

On 24 Nov 2025, at 09:59, Dimitry Andric <dim@FreeBSD.org> wrote:

On 24 Nov 2025, at 09:43, Peter Blok <pblok@bsd4all.org> wrote:

I have multiple systems which I update from the same 14-stable source with latest commit 465c30c4f202b02cd9cb12f12d9ea856c84c5203 of November 23.

I updated one system with installkernel installworld over NFS without problems. Next I did the build system that was having the src and obj, but it stopped with the installworld. Retrying the installworld resulted with the ld-elf.so.1: /usr/bin/cc: Undefined symbol rCLLLVMInitializeAArch64TargetInforCY message.

All systems are Intel or Amd, so IrCOm puzzled why the above symbol is needed. The only thing I can think of is that the build system builds all target compilers. The sucessfully installed system has a different src.conf without that option.

What is wrong here? The update sequence I use is always the same.

I think this is because your systems have been built with different src.conf configurations. These days /usr/bin/cc links to /usr/lib/libprivatellvm.so.19, so if you are installing world from a machine where src.conf options were different (in particular the WITHOUT_LLVM_TARGET_xxx options), there can be a mismatch between the symbols expected by the cc binary and the libprivatellvm.so.19 library.

During installworld there is a moment where the libprivatellvm.so.19 library is installed, and where /usr/bin/cc is not yet updated. Due to our build system running recursive make, and some of those Makefiles invoking /usr/bin/cc, you can run into this issue.

-Dimitry

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.stable

--00000000000054208b064458fec8
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Nov 24, 2025 at 4:55=E2=80=AFAM Peter Blok <pblok@bsd4all.org> wrot=
e:

Thanks for the explanation. This was a good lesson for me to setup an alternate boot environment with beadm.

You'd be even better off using bectl these days, since that's what's in
base. And I highly recommend it. A lot of the old tutorials still reference beadm, though.

Warner

I checked and the system with the problem is the build machine which has
the same src.conf for building and installing. So it must be related to t=

he

aborted install where /usr/lib was updated and /usr/bin was not.

Although I use the same source for all systems, I did a better job than I initially mentioned. All systems have the same src.conf when building nd installing.

Peter

On 24 Nov 2025, at 09:59, Dimitry Andric <dim@FreeBSD.org> wrote:

On 24 Nov 2025, at 09:43, Peter Blok <pblok@bsd4all.org> wrote:

I have multiple systems which I update from the same 14-stable source

with latest commit 465c30c4f202b02cd9cb12f12d9ea856c84c5203 of November 2=

3.

I updated one system with installkernel installworld over NFS without problems. Next I did the build system that was having the src and obj, bu=

t

it stopped with the installworld. Retrying the installworld resulted with
the ld-elf.so.1: /usr/bin/cc: Undefined symbol =E2=80=9CLLVMInitializeAArch64TargetInfo=E2=80=9D message.

All systems are Intel or Amd, so I=E2=80=99m puzzled why the above sym=

bol is

needed. The only thing I can think of is that the build system builds all target compilers. The sucessfully installed system has a different src.co=

nf

without that option.

What is wrong here? The update sequence I use is always the same.

I think this is because your systems have been built with different

src.conf configurations. These days /usr/bin/cc links to /usr/lib/libprivatellvm.so.19, so if you are installing world from a
machine where src.conf options were different (in particular the WITHOUT_LLVM_TARGET_xxx options), there can be a mismatch between the
symbols expected by the cc binary and the libprivatellvm.so.19 library.

During installworld there is a moment where the libprivatellvm.so.19

library is installed, and where /usr/bin/cc is not yet updated. Due to ou=

r

build system running recursive make, and some of those Makefiles invoking /usr/bin/cc, you can run into this issue.

-Dimitry

--00000000000054208b064458fec8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g= mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Nov 24,=
2025 at 4:55=E2=80=AFAM Peter Blok &lt;<a href=3D"mailto:pblok@bsd4all.org= ">pblok@bsd4all.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)= ;padding-left:1ex">Thanks for the explanation. This was a good lesson for m=
e to setup an alternate boot environment with beadm.<br></blockquote><div><= br></div><div>You&#39;d be even better off using bectl these days, since th= at&#39;s what&#39;s in base. And I highly recommend it. A lot of the old tu= torials still reference beadm, though.</div><div><br></div><div>Warner</div= ><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I checked and the system with the problem is the build machine which has th=
e same src.conf for building and installing. So it must be related to the a= borted install where /usr/lib was updated and /usr/bin was not.<br>

Although I use the same source for all systems, I did a better job than I i= nitially mentioned. All systems have the same src.conf when building nd ins= talling.<br>

Peter<br>



&gt; On 24 Nov 2025, at 09:59, Dimitry Andric &lt;dim@FreeBSD.org&gt; wrote= :<br>
&gt; <br>
&gt; On 24 Nov 2025, at 09:43, Peter Blok &lt;<a href=3D"mailto:pblok@bsd4a= ll.org" target=3D"_blank">pblok@bsd4all.org</a>&gt; wrote:<br>
&gt;&gt; <br>
&gt;&gt; I have multiple systems which I update from the same 14-stable sou= rce with latest commit 465c30c4f202b02cd9cb12f12d9ea856c84c5203 of November=
23.<br>
&gt;&gt; <br>
&gt;&gt; I updated one system with installkernel installworld over NFS with= out problems. Next I did the build system that was having the src and obj, = but it stopped with the installworld. Retrying the installworld resulted wi=
th the ld-elf.so.1: /usr/bin/cc: Undefined symbol =E2=80=9CLLVMInitializeAA= rch64TargetInfo=E2=80=9D message.<br>
&gt;&gt; <br>
&gt;&gt; All systems are Intel or Amd, so I=E2=80=99m puzzled why the above=
symbol is needed. The only thing I can think of is that the build system b= uilds all target compilers. The sucessfully installed system has a differen=
t src.conf without that option.<br>
&gt;&gt; <br>
&gt;&gt; What is wrong here? The update sequence I use is always the same.<=

&gt; <br>
&gt; I think this is because your systems have been built with different sr= c.conf configurations. These days /usr/bin/cc links to /usr/lib/libprivatel= lvm.so.19, so if you are installing world from a machine where src.conf opt= ions were different (in particular the WITHOUT_LLVM_TARGET_xxx options), th= ere can be a mismatch between the symbols expected by the cc binary and the=
libprivatellvm.so.19 library.<br>
&gt; <br>
&gt; During installworld there is a moment where the libprivatellvm.so.19 l= ibrary is installed, and where /usr/bin/cc is not yet updated. Due to our b= uild system running recursive make, and some of those Makefiles invoking /u= sr/bin/cc, you can run into this issue.<br>
&gt; <br>
&gt; -Dimitry<br>
&gt; <br>


</blockquote></div></div>

--00000000000054208b064458fec8--


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.stable

Peter Blok <pblok@bsd4all.org> writes:

Although I use the same source for all systems, I did a better job
than I initially mentioned. All systems have the same src.conf when
building nd installing.

Note that if you place a copy of src.conf in your shared source
directory, it will take precedence over the one found in /etc. That
saves you from having to keep it in sync.
DES
--
Dag-Erling Sm|+rgrav - des@FreeBSD.org
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.stable

On Mon, Nov 24, 2025 at 09:43:44AM +0100, Peter Blok wrote:

What is wrong here? The update sequence I use is always the same.

I had multiple issues of *this type* but with amd64, going from
stable/14 to stable/15. I can't remember them all exactly.

What fixed them all for me was starting afresh with an
empty /usr/obj.

For good measure, I deleted all that was in /var/cache/ccache/*
and then in /usr/src make -j10 cleanworld cleandir clean.

Then the usual make -j10 kernel && reboot then
make -j10 buildworld etc etc

Maybe this'll work for you. Good luck.
--


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: muc.lists.freebsd.stable

Thanks all for the good advice. I hosed the box trying to figure out how to resolve the problem. While doing so I copied wrong combinations and hosed the box. Booted stable memstick and copied /lib /libexec and /usr/bin and the system came back up. Next I did the clean build and installworld and everything is ok now. IrCOm now using bectl and install with DESTDIR

On 25 Nov 2025, at 14:11, void <void@f-m.fm> wrote:

N++On Mon, Nov 24, 2025 at 09:43:44AM +0100, Peter Blok wrote:

What is wrong here? The update sequence I use is always the same.

I had multiple issues of *this type* but with amd64, going from stable/14 to stable/15. I can't remember them all exactly.

What fixed them all for me was starting afresh with an
empty /usr/obj.

For good measure, I deleted all that was in /var/cache/ccache/*
and then in /usr/src make -j10 cleanworld cleandir clean.

Then the usual make -j10 kernel && reboot then make -j10 buildworld etc etc

Maybe this'll work for you. Good luck.
--

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de
--- Synchronet 3.21a-Linux NewsLink 1.2