this post was submitted on 21 Jul 2023
1048 points (98.6% liked)

linuxmemes

21263 readers
1871 users here now

Hint: :q!


Sister communities:


Community rules (click to expand)

1. Follow the site-wide rules

2. Be civil
  • Understand the difference between a joke and an insult.
  • Do not harrass or attack members of the community for any reason.
  • Leave remarks of "peasantry" to the PCMR community. If you dislike an OS/service/application, attack the thing you dislike, not the individuals who use it. Some people may not have a choice.
  • Bigotry will not be tolerated.
  • These rules are somewhat loosened when the subject is a public figure. Still, do not attack their person or incite harrassment.
  • 3. Post Linux-related content
  • Including Unix and BSD.
  • Non-Linux content is acceptable as long as it makes a reference to Linux. For example, the poorly made mockery of sudo in Windows.
  • No porn. Even if you watch it on a Linux machine.
  • 4. No recent reposts
  • Everybody uses Arch btw, can't quit Vim, and wants to interject for a moment. You can stop now.

  • Please report posts and comments that break these rules!

    founded 1 year ago
    MODERATORS
     
    you are viewing a single comment's thread
    view the rest of the comments
    [–] [email protected] 14 points 1 year ago (1 children)

    Oddly, Gentoo was where I started out when I got serious about using Linux. That was when I was in my 20’s and I wanted to get every last bit of performance out of my computer. Also, breaking stuff was fun and gave me a chance to figure new stuff out.

    Now I just want stuff to work and be relatively up to date. So I use Debian testing.

    [–] [email protected] 1 points 1 year ago (1 children)

    I've found a good compromise between the two. I've disabled most of the desktop profile USE flags and I compile everything with -Ofast and LTO

    Portage errors are uncommon, and build failures are easily fixed by disabling compilation flags from package.env. Build failures get less and less common as package.env grows (it's currently at about 20 lines)

    As for the kernel, I just started with a distribution kernel, disabled all modules and only enabled the ones that I need (this can automatically be done with make localmodconfig). These modules are built-in (so lsmod usually returns nothing)

    I chose systemd because of the huge increase in boot speed

    [–] [email protected] 2 points 1 year ago* (last edited 1 year ago) (1 children)

    Compiling everything with LTO landed me in a situation where a bunch of packages fail to build because apparently having some LTO'd static libraries can cause issues.

    I'm now going to start investigating where exactly the issue is. Trouble is, the package that was giving me errors, depended on a whole lot of static libraries, soooooo.... Good luck to me.

    Being an ultra-madlad, I used to also -ffast-math everything that didn't fail, but because I didn't know about package.env yet, I found it easier to just keep it off rather than turning it off and on again every time I needed to emerge something that failed because of it.

    [–] [email protected] 1 points 1 year ago* (last edited 1 year ago)

    apparently having some LTO’d static libraries can cause issues

    Yeah, I think I've had that problem once or twice. I think I found the culprits by disabling all build flags for libraries that seemed related, rebuilding them, running emerge @preserved-rebuild and then repeating the process to narrow it down

    dmesg and PFL help with diagnosing crashes due to libraries, but I don't think that would help here

    If it helps, here's my package.env:

    # Build failures
    app-emulation/wine-vanilla noflto O3
    sys-apps/groff O3
    dev-lang/rust noflto
    dev-lang/python O3
    sys-auth/polkit O3
    sys-libs/libomp noflto
    sys-libs/compiler-rt noflto
    net-libs/nodejs O3
    dev-lang/duktape O3
    x11-drivers/xf86-video-intel noflto
    
    # Runtime failures
    gnome-extra/cjs noflto O3
    sys-devel/llvm noflto