Problem with installation - llvm compilation error

[whatiswhat]

Hello good people,

Here is the last screen of error:

[NeddySeagoon]

whatiswhat,

Welcome back, we know you would come, just not when. :)

Please put the build log /var/tmp/portage/sys-devel/llvm-10.0.1/temp/build.log onte a pastebin site.
With 4G RAM and MAKEOPTS="-j5" you are goint to run out of RAM or some of the larger C++ packages.
They can take 2G RAM per make thread, so -j5 may want 10G RAM for C++

The build log and dmesg may show that the Out Of Memory (OOM) manager has killed one of your make threads.

The fix is to reduce MAKEOPTS="-j5" for bigger C++ jobs.
Portage can do that for you, if it is the cause of your build failure.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[x90e]

Also, assuming you have portage compiling under a tmpfs RAMDISK, I would reboot and try again.

[whatiswhat]

[x90e]

Are you using a tmpfs mount for portage @ /var/tmp ? you might just need to make it bigger.

[Ionen]

[x90e]

yeah that's what you're getting? the out of memory killer kicks in when you don't have enough memory. you can set the tmpfs to be 4gb. I've got a dell laptop with 8GB of ram and i've had to set the tmpfs to 10GB for compiling chrome/rust/llvm/ etc. I was getting the same messages you are, processes just randomly being killed.

[Ionen]

[NeddySeagoon]

whatiswhat,

[x90e]

[NeddySeagoon]

x90e,

If tmpfs is empty, it takes up no RAM and the RAM can be used for other things.
The size, by default, 50% of RAM is an upper limit.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[x90e]

[Ionen]

[x90e]

[Hu]

Ideally, you would keep everything related to emerge and all its subprocesses entirely in RAM: tmpfs for the files, and never swap out any of the pages used for application data. That would give you RAM-speed response times for anything related to the build. In practice, we assume most people don't have 64GB of RAM, and from there assume that, for large projects such as Chromium, the filesystem size of the sources+objects, plus the RAM requirements for the application data (compiler data structures, Make or equivalent dependency tree data, etc.), will exceed available physical RAM, at which point you start swapping. If you swap, then some accesses occur at disk speed, rather than RAM speed. If the kernel makes non-ideal choices for what to swap, then you may incur disk speed accesses rather more often than needed, as the kernel wastes RAM keeping resident things you could have happily swapped out, while shuffling the valuable pages you want to access in and out of main memory. If you swap to a spinning drive, rather than an SSD/NVMe, then swap speed is horrible compared to RAM speed.

The advice to move the files out of tmpfs is based on the idea that this will discourage the kernel from keeping in-memory copies of things that you would prefer to page out, like object files that have already been compiled, which will not be needed again until link time. By encouraging the kernel to page out sources/objects, you hopefully free up enough RAM that you never swap out the pages you most need to keep in-memory: the compiler's code, commonly re-read headers, etc. If your system can handle running the entire build in RAM, without using swap, feel free to do so. It almost certainly will be no worse than writing the data to disk, and will likely be at least a little bit better.

[NeddySeagoon]

x90e,

Swap access is slower than file read/writes.
When you force tmpfs to write to swap, its slower than writing the same data to a file.

Ponder this. If you have enough RAM to put /var/tmp/portage into tmpfs, you don't gain any speed by doing so because the kernel will keep everything cached anyway.
You do save a lot of writes that will never be read but they are effectively 'free' as the transfers are done by DMA.
You have to use the CPU to set up the DMA and it it does take a little memory bandwidth for the transfer.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[x90e]

[whatiswhat]

NeddySeagoon,

It seems taht you were right because it has took more time but llvm have compiled without any errors.

I would also like to note that information about possible compilation errors caused by small and insufficient amount of RAM needed to handle the -j5 threads should be corrected/added/completed on the wiki page which I was based on to tweak my make.conf:

https://wiki.gentoo.org/wiki/Intel_Core_2

[NeddySeagoon]

x90e,

Lets suppose you have a very large RAM. So large, that for a small package, (no numbers) that no writes to HDD are required.
They may happen but they are not required.
You run

[x90e]

[NeddySeagoon]

x90e,

Its in RAM until the pressure on RAM means that something must be evicted.
It will be written to disk and remain in RAM too, depending on the commit frequency of the filesystem.
Filesystems have a maximum time dirty buffers are allowed to exist.

When the kernel goes to read something from the HDD and finds it already cached, the read will not happen.

That 34GiB in my buffers will have been committed to the HDD as I use ext4.
Its writes that will never be read until the cache is cleared though.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[Hu]

It stays in RAM until the kernel has a better use for the RAM. In particular, it remains in RAM as a cached disk page even after the data is successfully written to disk. Then, if you try to read back the file you just wrote, the kernel can notice that it still has a copy of that page in memory, can assume the disk would just return that page unchanged if asked, and can then short-circuit the read by using the in-memory page without reloading it from disk. The write to the disk happened in the background, so it may not slow down the writing of the file at all, assuming the written file data fits entirely within the RAM used for disk pages. If you get very lucky, the kernel might defer writing the disk blocks for so long that the file gets deleted before it is ever persisted to disk, at which point the kernel can eliminate the write to disk. (It may still need to update directory control data to reflect that the file vaguely existed for a time, but it can skip writing the file's data.)

[NeddySeagoon]

x90e,

discard in fstab may be a very bad thing.

discard is not supposed to be a command to the drive to do anything. Its supposed to keep track of discarded space and only erase it when it needs to.
This implementation minimises write amplification, which is caused when an erase block (to be erased) contains some still in use write blocks.
The still used blocks have to be moved.

Many poor implementations of discard implement it as a command to be acted on immediately.
This causes a great deal of write amplification.

Running fstrim in a cron job is safer.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[x90e]

[NeddySeagoon]

x90e,

Nobody knows how many implementations of discard there are.

Regardless, the kernel sends discard information to the drive, thats the same for everyone.
Its what the drive does with the information once it gets it that matters and thats propriatary information.

We do know when it goes wrong. Like there have been drives that incorrectly erased LBA 0.
That's the MSDOS partition table, so there were some unhappy users.

Keep an eye on your lifetime parameters in