In my 13.2-p9 I have llvm12,llvm13,and llvm15@default
installed,and apparently there are versions out to llvm18
in the ports collection along with an llvm-devel.
Is it possible to standardize on one at a time or do
individual ports dependences require different
versions?
On 2024-02-16, Louis Epstein <le@main.lekno.ws> wrote:
In my 13.2-p9 I have llvm12,llvm13,and llvm15@default
installed,and apparently there are versions out to llvm18
in the ports collection along with an llvm-devel.
Do you build from ports or do you install packages?
Is it possible to standardize on one at a time or do
individual ports dependences require different
versions?
Certain ports are tied to specific versions from time to time. This
keeps changing. I'm on 14.0-STABLE with llvm17 as the base system
compiler, and I only have an additional llvm15 installed, which was
still required for building firefox the last time I checked.
Over time, there's a tendency to accumulate llvm versions on your
system that aren't actually used for anything any longer.
Over time, there's a tendency to accumulate llvm versions on your
system that aren't actually used for anything any longer.
Hm,looks like llvm12 is now gone.
I have llvm13-13.0.1_7 and llvm15-15.0.7_10 in place.
I have upgraded the base OS to 13.2-RELEASE-p10.
Would llvm versions past 15 work?
On 2024-02-19, Louis Epstein <le@main.lekno.ws> wrote:
Over time, there's a tendency to accumulate llvm versions on your
system that aren't actually used for anything any longer.
Hm,looks like llvm12 is now gone.
I have llvm13-13.0.1_7 and llvm15-15.0.7_10 in place.
My low-effort approach is this: When I see that the llvm ports will
be rebuilt anyway, I deinstall them. The ones actually required
as dependencies will come back, at no extra compile cost.
I have upgraded the base OS to 13.2-RELEASE-p10.
Would llvm versions past 15 work?
Work for what?
If a certain port has a fixed dependency on a particular llvm version
then having newer llvm versions installed doesn't affect this. For
instance, Firefox and Mesa require llvm15 at the moment.
Grepping for LLVM_VERSION over the ports tree shows that for all
llvm versions from 11 to 16, there's at least one port that wants
this particular version.
Christian Weisgerber <naddy@mips.inka.de> wrote:
On 2024-02-19, Louis Epstein <le@main.lekno.ws> wrote:
Over time, there's a tendency to accumulate llvm versions on your
system that aren't actually used for anything any longer.
Hm,looks like llvm12 is now gone.
I have llvm13-13.0.1_7 and llvm15-15.0.7_10 in place.
My low-effort approach is this: When I see that the llvm ports will
be rebuilt anyway, I deinstall them. The ones actually required
as dependencies will come back, at no extra compile cost.
I have upgraded the base OS to 13.2-RELEASE-p10.
Would llvm versions past 15 work?
Work for what?
If a certain port has a fixed dependency on a particular llvm version
then having newer llvm versions installed doesn't affect this. For
instance, Firefox and Mesa require llvm15 at the moment.
I have them running,I assume at some point they switched to it
from llvm13.
Grepping for LLVM_VERSION over the ports tree shows that for all
llvm versions from 11 to 16, there's at least one port that wants
this particular version.
I suppose nothing I have installed wants 16,or 16 would be added.
Well,last night I tried deleting llvm12 and got back a message
indicating that it wasn't there (normally I'd get a message
indicating what would be deleted along with it,if I recall
previous attempts correctly).
...and when I next launched X,I found it failed via segmentation
fault when I tried launching Seamonkey (I run Seamonkey,which is
no longer in the ports tree to my annoyance,for legacy reasons).
And I tried putting llvm12 back but now X won't launch at all
(first fails pointed to xorg.3.log and recent to xorg.0.log).
I can't think of anything else I did that would have made X
stop working but I'm doing a new synth prepare-system,will
see what results.
-=-=-
The World Trade Center towers MUST rise again,
at least as tall as before...or terror has triumphed.
Louis Epstein <le@main.lekno.ws> wrote:
Christian Weisgerber <naddy@mips.inka.de> wrote:
On 2024-02-19, Louis Epstein <le@main.lekno.ws> wrote:
Over time, there's a tendency to accumulate llvm versions on your
system that aren't actually used for anything any longer.
Hm,looks like llvm12 is now gone.
I have llvm13-13.0.1_7 and llvm15-15.0.7_10 in place.
My low-effort approach is this: When I see that the llvm ports will
be rebuilt anyway, I deinstall them. The ones actually required
as dependencies will come back, at no extra compile cost.
I have upgraded the base OS to 13.2-RELEASE-p10.
Would llvm versions past 15 work?
Work for what?
If a certain port has a fixed dependency on a particular llvm version
then having newer llvm versions installed doesn't affect this. For
instance, Firefox and Mesa require llvm15 at the moment.
I have them running,I assume at some point they switched to it
from llvm13.
I've just been doing a long synth run that has had llvm12,
llvm13,
and llvm15@default building in parallel.
I noted that when llvm12 finished,
openjdk11 started (not having started before
despite open build channels).
When llvm15@default finished,
mesa-libs,
qt6-tools,
and firefox started.
At this writing llvm13 is still building.
Grepping for LLVM_VERSION over the ports tree shows that for all
llvm versions from 11 to 16, there's at least one port that wants
this particular version.
I suppose nothing I have installed wants 16,or 16 would be added.
I see that 13.3-RELEASE adds 17,
so will this solve problems
when I upgrade from 13.2 or make
them more complicated?
Well,last night I tried deleting llvm12 and got back a message
indicating that it wasn't there (normally I'd get a message
indicating what would be deleted along with it,if I recall
previous attempts correctly).
...and when I next launched X,I found it failed via segmentation
fault when I tried launching Seamonkey (I run Seamonkey,which is
no longer in the ports tree to my annoyance,for legacy reasons).
And I tried putting llvm12 back but now X won't launch at all
(first fails pointed to xorg.3.log and recent to xorg.0.log).
I can't think of anything else I did that would have made X
stop working but I'm doing a new synth prepare-system,will
see what results.
This has still not resolved...I can not launch seamonkey or firefox
without fvwm crashing if it even starts in the first place.
-=-=-
The World Trade Center towers MUST rise again,
at least as tall as before...or terror has triumphed.
Louis Epstein <le@main.lekno.ws> wrote:
My FTP upgrade from 13.2 to 13.3
has unexpectedly crashed everything
(here I am posting from a backup account
from an Ubuntu partition).
I can boot single-user on the SSD but
any attempt to go multi-user produces
a crash on a kldload process.
The messages with regard to the page panic
include a kdb backtrace listing
vpanic
panic
trap_fatal
trap_pfault
calltrap
ttm_bo_validate
ttm_bo_init_reserved
ttm_bo_init
radeon_bo_create
radeon_ttm_init
si_init
radeon_device_init
radeon_driver_load_kms
drm_dev_register
radeon_pci_probe
linux_pci_attach_device
device_attach
and it hits around kernel module loading time after the uhubs.
Any idea if there's a way to get a working 13.3 install without
destroying the existing accounts and so forth?
(I backed up a lot of the SSD's key partitions to an HDD but
rebuilding is quite a chore.The DVDs don't seem usable for
upgrading an existing FreeBSD installation,only for making
new ones?)
Boot to single-user mode (2 in the boot menu). When you
get to the root# prompt.
For UFS2 system, do
# fsck -y
# fsck -y
I don't use ZFS, so don't know if the above matters.
# mount -a
On Wed, 13 Mar 2024 00:37:39 +0000, Louis Epstein wrote:
Louis Epstein <le@main.lekno.ws> wrote:
My FTP upgrade from 13.2 to 13.3
has unexpectedly crashed everything
(here I am posting from a backup account
from an Ubuntu partition).
I can boot single-user on the SSD but
any attempt to go multi-user produces
a crash on a kldload process.
The messages with regard to the page panic
include a kdb backtrace listing
vpanic
panic
trap_fatal
trap_pfault
calltrap
ttm_bo_validate
ttm_bo_init_reserved
ttm_bo_init
radeon_bo_create
radeon_ttm_init
si_init
radeon_device_init
radeon_driver_load_kms
drm_dev_register
radeon_pci_probe
linux_pci_attach_device
device_attach
and it hits around kernel module loading time after the uhubs.
Any idea if there's a way to get a working 13.3 install without
destroying the existing accounts and so forth?
(I backed up a lot of the SSD's key partitions to an HDD but
rebuilding is quite a chore.The DVDs don't seem usable for
upgrading an existing FreeBSD installation,only for making
new ones?)
Boot to single-user mode (2 in the boot menu). When you
get to the root# prompt.
For UFS2 system, do
# fsck -y
# fsck -y
I don't use ZFS, so don't know if the above matters.
# mount -a
# vi /etc/rc.conf
<comment out kld_list="radeaon_yada" line>
# sync
# exit
You should end up in a console, i.e., no X11 window.
Log in as root.
Assuming you have a populated /usr/ports,
% pkg info | grep kmod
drm-515-kmod-5.15.118_3
gpu-firmware-amd-kmod
...
gpu-firmware-radeon-kmod-verde
% portmaster -Byd drm-515-kmod
% portmaster -Byd gpu-firmware\*
% vi /etc/rc.conf
<uncomment out kld_list="radeaon_yada" line>
% sync
% shutdown -r now
Steven G. Kargl <sgk@removetroutmask.apl.washington.edu> wrote:
On Wed, 13 Mar 2024 00:37:39 +0000, Louis Epstein wrote:
Louis Epstein <le@main.lekno.ws> wrote:
My FTP upgrade from 13.2 to 13.3
has unexpectedly crashed everything
(here I am posting from a backup account
from an Ubuntu partition).
I can boot single-user on the SSD but
any attempt to go multi-user produces
a crash on a kldload process.
The messages with regard to the page panic
include a kdb backtrace listing
vpanic
panic
trap_fatal
trap_pfault
calltrap
ttm_bo_validate
ttm_bo_init_reserved
ttm_bo_init
radeon_bo_create
radeon_ttm_init
si_init
radeon_device_init
radeon_driver_load_kms
drm_dev_register
radeon_pci_probe
linux_pci_attach_device
device_attach
and it hits around kernel module loading time after the uhubs.
Any idea if there's a way to get a working 13.3 install without
destroying the existing accounts and so forth?
(I backed up a lot of the SSD's key partitions to an HDD but
rebuilding is quite a chore.The DVDs don't seem usable for
upgrading an existing FreeBSD installation,only for making
new ones?)
Boot to single-user mode (2 in the boot menu). When you
get to the root# prompt.
For UFS2 system, do
# fsck -y
# fsck -y
I don't use ZFS, so don't know if the above matters.
# mount -a
# vi /etc/rc.conf
<comment out kld_list="radeaon_yada" line>
# sync
# exit
You should end up in a console, i.e., no X11 window.
Log in as root.
Assuming you have a populated /usr/ports,
% pkg info | grep kmod
drm-515-kmod-5.15.118_3
what's on my system is
drm-510-kmod-5.10.163_9
and
drm-kmod-20220907_2
gpu-firmware-amd-kmod
...
gpu-firmware-radeon-kmod-verde
% portmaster -Byd drm-515-kmod
% portmaster -Byd gpu-firmware\*
% vi /etc/rc.conf
<uncomment out kld_list="radeaon_yada" line>
% sync
% shutdown -r now
The fix appears to have worked,BUT
I have not received a prompt to recompile
all applications that the freebsd.org
instructions for a binary upgrade indicated
would happen at this stage.
I normally upgrade applications via
git -C /usr/ports pull [updating ports collection]
synth status [checking what's needed at the moment]
synth prepare-system [updating available packages]
pkg upgrade -r Synth [installing the new stuff]
and have done none of these since updating the OS except
for a synth status that tells me nothing needs upgrades
and 13 that wanted rebuilds or replacements
before the OS upgrade still do.
Do I have to trigger the rebuild somehow or can I update
the ports collection without screwing up?
-=-=-
The World Trade Center towers MUST rise again,
at least as tall as before...or terror has triumphed.
Steven G. Kargl <sgk@removetroutmask.apl.washington.edu> wrote:
Assuming you have a populated /usr/ports,
% pkg info | grep kmod
drm-515-kmod-5.15.118_3
what's on my system is
drm-510-kmod-5.10.163_9
and
drm-kmod-20220907_2
gpu-firmware-amd-kmod
...
gpu-firmware-radeon-kmod-verde
% portmaster -Byd drm-515-kmod
% portmaster -Byd gpu-firmware\*
% vi /etc/rc.conf
<uncomment out kld_list="radeaon_yada" line>
% sync
% shutdown -r now
The fix appears to have worked,BUT
I have not received a prompt to recompile
all applications that the freebsd.org
instructions for a binary upgrade indicated
would happen at this stage.
I normally upgrade applications via
git -C /usr/ports pull [updating ports collection]
synth status [checking what's needed at the moment]
synth prepare-system [updating available packages]
pkg upgrade -r Synth [installing the new stuff]
and have done none of these since updating the OS except
for a synth status that tells me nothing needs upgrades
and 13 that wanted rebuilds or replacements
before the OS upgrade still do.
Do I have to trigger the rebuild somehow or can I update
the ports collection without screwing up?
...in any case my failure to launch X successfully
since the flirtation with removing llvm12 and putting
it back has NOT been solved by upgrading 13.2->3.
-=-=-
The World Trade Center towers MUST rise again,
at least as tall as before...or terror has triumphed.
Louis Epstein <le@main.lekno.ws> wrote:
...in any case my failure to launch X successfully
since the flirtation with removing llvm12 and putting
it back has NOT been solved by upgrading 13.2->3.
The problem started when I deleted LLVM12 and did not go
away when I reinstalled it...and deleting and reinstalling
xinit has made no difference.
Either nothing at all starts,
or it starts and aborts,
or the windows come up in the
window manager and either
attempting to launch an application
crashes it or the keyboard and mouse
are no longer able to make inputs
and I have to restart.
What needs to be redone to again
have a working X?
If I get in your situtation, I typically rebuild everything
from source. So, first created a backup, then do
In article <usvdns$1oga4$1@dont-email.me>,
Steven G. Kargl <sgk@REMOVEtroutmask.apl.washington.edu> wrote:
If I get in your situtation, I typically rebuild everything
from source. So, first created a backup, then do
Forcibly reinstalling the packages might re-add whatever dependency
the OP broke by deleting LLVMs.
# pkg upgrade -f
If one is rebuilding everything from ports, then one is
not dealing with the nightmare of dependencies from pre-built
packages (which may be out-of-sync given the dependency tree
and how the ports tree is managed) or from stale things in
a search path. There is also the possibility to tailor the
In article <usvik9$1pnnp$1@dont-email.me>,
Steven G. Kargl <sgk@REMOVEtroutmask.apl.washington.edu> wrote:
If one is rebuilding everything from ports, then one is
not dealing with the nightmare of dependencies from pre-built
packages (which may be out-of-sync given the dependency tree
and how the ports tree is managed) or from stale things in
a search path. There is also the possibility to tailor the
pkg(8) can clean up outdated dependencies.
# pkg autoremove
Started with a completely bare
/usr/local may be prudent.
On Thu, 14 Mar 2024 14:19:04 +0000, Louis Epstein wrote:
Louis Epstein <le@main.lekno.ws> wrote:
...in any case my failure to launch X successfully
since the flirtation with removing llvm12 and putting
it back has NOT been solved by upgrading 13.2->3.
The problem started when I deleted LLVM12 and did not go
away when I reinstalled it...and deleting and reinstalling
xinit has made no difference.
Either nothing at all starts,
or it starts and aborts,
or the windows come up in the
window manager and either
attempting to launch an application
crashes it or the keyboard and mouse
are no longer able to make inputs
and I have to restart.
What needs to be redone to again
have a working X?
If I get in your situtation, I typically rebuild everything
from source. So, first created a backup, then do
% cd /usr/src
% git stash
% git pull -ff
% git stash pop
% rm -rf /usr/obj/*
% make -j8 buildworld <-- I have 8 cores.
% make -j8 buildkernel
% make installkernel
<reboot in single user>
% mount -a
% etcupdate -p
% cd /usr/src
% make installworld
% etcupdate -B
% make delete-old
% make delete-old-lib <-- Only if I want a very clean world
<reboot without X11, so remove kld_load in rc.conf>
Now, the ports.
Steven G. Kargl <sgk@removetroutmask.apl.washington.edu> wrote:
On Thu, 14 Mar 2024 14:19:04 +0000, Louis Epstein wrote:
Louis Epstein <le@main.lekno.ws> wrote:
...in any case my failure to launch X successfully
since the flirtation with removing llvm12 and putting
it back has NOT been solved by upgrading 13.2->3.
The problem started when I deleted LLVM12 and did not go
away when I reinstalled it...and deleting and reinstalling
xinit has made no difference.
Either nothing at all starts,
or it starts and aborts,
or the windows come up in the
window manager and either
attempting to launch an application
crashes it or the keyboard and mouse
are no longer able to make inputs
and I have to restart.
What needs to be redone to again
have a working X?
If I get in your situtation, I typically rebuild everything
from source. So, first created a backup, then do
What in toto needs to be backed up?
# pkg delete $(pkg info|grep -v '^pkg-'|awk '{print $1}')
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 379 |
Nodes: | 16 (2 / 14) |
Uptime: | 43:54:27 |
Calls: | 8,141 |
Calls today: | 4 |
Files: | 13,085 |
Messages: | 5,857,952 |