Compiler tools which should be only build-only dependencies

My harddisk for storage failed, and I couldn't access it at all using the FreeBSD boot CD or a Linux rescue CD. It got a CAM error when booting FreeBSD, from the harddisk that didn't fail. I couldn't access the literal drive in the FreeBSD CD nor from a Linux rescue CD.

My harddisk failed, when I was impatient on a jail console command line, in the middle of it installing LLVM asked for by an Xorg related package. It led me to wonder, why LLVM is needed for more than a build only dependency. From Freshports, it was perhaps because of Mesa.

Then, I wondered why Rust is not only a build only dependency for a few programs that ask for it.

I remember that programs that used build only dependencies, didn't install those as packages.

When I get to, I'll get on the mailing list. If these programs need LLVM or Rust as more than build only dependencies, they should be flavors or be their own separate package. As some packages of the same port have nox11 or x11 by the name.

The problem is more than this, as the way these LLVM dependencies are set it, it requires the most latest version by use of /usr/ports/Mk/, and it often requires a complete deletion of a lot of ports simply because they once relied on another version or any version of LLVM. There needs to be a leniency, as any version above a certain LLVM will be accepted for other programs which don't use it as more than a build-only dependency, so they don't have to be deinstalled and reinstalled because an unrelated program required the latest LLVM version that's sometimes not even as a package yet.

Off topic from this thread. When I get my system back up, I need to solve how to get a jail to use RAM for compiling in a uniform way. It may be a simple solution, though I can't see it from without being on a FreeBSD system. Now that I think of it, I'll try the command argument in a jail template to add the line to use a RAM filesystem to fstab. I wasn't building at the time, but building may have added wear to the harddisk. It wasn't even that much wear.
 
I'm not sure that llvm is a build only dependency. That is a different question from "should it be a build only dependency".
Some ports (in the X path) use it for preprocessing stuff, like xrdb and merging resources.
A different question is "do we really need llvm from ports instead of base"? That, I don't know.
Seems like there are a number of different versions of llvm available in pkgs and whatever is in base.
I would have though "llvm devel and llvm current LTS" would be the only versions around.
But what do I know, I'm a bit rusty on all the actual needs of different ports.
 
My harddisk failed, when I was impatient on a jail console command line,
Please my friend. I know you know better than that.
Obviously it was near death and you might have pushed it, but I doubt you caused it.

I guess it does show the importance of running smartmon reports regularly.
It's still not a genie. Disk parts fail that are not monitored.
 
I need to solve how to get a jail to use RAM for compiling in a uniform way.
I don't know about your experiences but mine is that base compiling uses little RAM.
Cores and disk speed make it quicker. RAM really plays no part in compilation speed.
Now if you are using ZFS I do digress.

The nice thing about using jails instead of VM's is raw disk speed. No virt disk hit. No passthru hit on NVMe.
Disk speed is a huge part of the equation. Over 50 cores is nice too. FreeBSD spreads the load so well.
I don't remember doing anything special for RAM in jails.

I need to solve how to get a jail to use RAM for compiling in a uniform way. It may be a simple solution, though I can't see it from without being on a FreeBSD system.
rctl -a jail:httpd:memoryuse:deny=2G/jail
 
Building on a RAM filesystem, instead of compiling on the harddrive. md, tmpfs or I don't remember what it was that I had on my harddrive. One of these works better, as it uses the harddisk or swap space when RAM becomes full. It was to reduce wear on the harddrive, but also for speeding builds. Mostly to reduce wear. It was about 2 years old, and didn't have lots of wear anyway.

For ports that have lots of dependencies, more RAM and SWAP space is used. Base builds use less than ports with heavy dependencies. Kernel builds use even less.

Heat and humidity may have played a part the other day, as I heard grinding noises days before.

Resource limits of RAM would be needed for running programs like Firefox. This can be done from a jail, but preferably any other way, which might not be available. I've seen the Howto for running Firefox from a jail on the host, but didn't get around to figuring that out. Running Firefox which has runaway resources could have contributed too, as it caused a recoverable crash soon before also. I didn't fully understand the part of Resource Limits from the manual for what would suit my purposes yet, but I could try this for each user, even if it limits it. At least it wouldn't crash or strain due to runaway processes.

I had Bastille in its own partition too, but next time, I'm putting executables and jails on a harddrive separate from other files. I'll also go with xterm for my background terminals that don't need transparency or unicode over rxvt-unicode. I'll pull up a unicode or transparent terminal as I need them.
 
Heat and humidity may have played a part the other day, as I heard grinding noises days before.
Humidity should be controlled by drive breather.
Heat is another topic altogether. That is the rotating assembly killer.

Getcha a 2TB NVMe Intel/Samsung/Kioxa and spool the big stuff to a pile of rust.
 
Seems like there are a number of different versions of llvm available in pkgs and whatever is in base.
I would have though "llvm devel and llvm current LTS" would be the only versions around.
But what do I know, I'm a bit rusty on all the actual needs of different ports.
For a while MySQL would not compile with the version in base, so it specifically pulled in another version of LLVM to build MySQL.

There may be other ports in the same position.
 
  • Like
Reactions: mer
I know I am going to sound like the devil spawn here but what about an LLVM runtime executable or whatever.
Better than the whole LLVM compiler for a -runs- dependency.
Why don't we use that method? That is the core problem here right?
LLVM is a runtime dependency on programs for some component of LLVM. Can't it be broke out?
Is my assumption wrong?
 
Both are SSD consumer drives by Inland.

The older one of 120MB is still running without problems, except the pins to the cable twisted, but still connects well enough to run without problems.

The newer one that malfunctioned is of 256MB. It has SATA III capacity.

I believe it's the SSD technology, which isn't mature. The good thing about these is that they're made in Taiwan.

Once, over a decade ago, I damaged a SATA drive by physically handling it without extra care. Don't remember the brand. I didn't pay attention that the circuit board was exposed, unlike optical drives. That was a rare error, I've made.

The prices on many of these same drives has come off down since.
 
I believe it's the Clang part that's needed for programs that specifically ask for a newer version. They didn't want to split it off from LLVM. They need their own library that's in addition to Clang or LLVM. This is a lack of standardization that so many LLVMs cause unrelated programs to be reinstalled.

Rust also asks for newer versions, and has two different types of builds, but at least with Rust, it's standardized enough, that multiple version numbers except for the newest one aren't needed.
 
consumer drives by Inland.
We have found the problem.
There is no way I use off brand drives. KingSpec ect...
Wear leveling is not easy and requires expertise.

Lowest I go is Sandisk X series drives. Micron DC drives been good. Innodisk is rock solid.
$100/terrabyte for quality SATA or NVMe seems about right. Premium on enterprise drives.
 
Once, over a decade ago, I damaged a SATA drive by physically handling it without extra care. Don't remember the brand. I didn't pay attention that the circuit board was exposed, unlike optical drives. That was a rare error, I've made.
I am amazed at the resiliency of SSD's.
My Dell laptops have a door for the hard disk and I run without it.
Commonly the cat attacked something onscreen.
Occasionally the SSD comes flying out too.
Slide her back in and reboot. Ahhhh.
Technology is a great thing.
 
I think I blew out my other SSD drive and the motherboard. These things are too delicate. I should have left the broken one in.

I'm not using the SATA cables that have the clips on them for delicate drives. I might not use them at all anymore. The plastic part broke off before, so the metal pieces show, and it's difficult to connect the SATA cable to it, and it falls out easily. I was careful in physically handling it, but I should have turned it off, thinking it was ok, bc SATA was plug and play. A metal piece touched, as I could hear it. I wish I left it in, and merely disconnected the broken drive.

I disconnected it, bc it gave CAM errors on bootup, and I wish I stopped there.

I thought the culprit was overheating, bc it was too close to the bottom, but there was still room for air, and a fan in front of it.

There's a chance my motherboard might be ok.
 
Back
Top