DEV Community: Daniel

[Boost]

Daniel — Sun, 23 Aug 2026 03:12:31 +0000

Pramod Boda

Feb 21 '25

Recommended Industry-Standard React.js Folder Structure

#react #reactjsdevelopment #folderstructure #webdev

270

4 min read

Fixing "g++ Not Found" When Debugging Rails in RubyMine on Fedora

Daniel — Mon, 17 Aug 2026 03:10:57 +0000

Fixing "g++ Not Found" When Debugging Rails in RubyMine on Fedora

TL;DR: If clicking "Debug" in RubyMine on Fedora fails to install debase because of a missing g++ compiler, the standard @development-tools group might not be enough. Run sudo dnf install gcc-c++ make redhat-rpm-config to get the explicit C++ compiler and tools Ruby needs to build native extensions.

I was recently working on a Rails app on my Fedora machine and wanted to step through some code. I fired up RubyMine, set my breakpoints, and clicked the "Debug" button, fully expecting everything to just work.

Instead, RubyMine tried to automatically install the debase and ruby-debug-ide gems—which it needs under the hood to hook into the Ruby process—and threw a massive wall of error text at me.

The core of the failure looked like this:

Building native extensions. This could take a while...
ERROR:  Error installing debase-3.0.17.gem:
    ERROR: Failed to build gem native extension.
...
/path/to/extconf_common.rb:80:in 'Kernel#`': No such file or directory - g++ (Errno::ENOENT)

My system was essentially complaining that it couldn't find g++, the C++ compiler.

The Initial (Failed) Attempt

My first thought was, "Oh, I must have forgotten to install the base build tools on this machine."

Since I'm on Fedora, I reached for the standard DNF command to pull in the development group:

sudo dnf install @development-tools

(Note: If you're on older versions of Fedora, you might be used to dnf groupinstall "Development Tools", but DNF5 uses the @ syntax or space-separated group install).

It downloaded and installed a bunch of packages. I felt confident, went back to RubyMine, clicked "Debug" again, and... got the exact same No such file or directory - g++ error.

Why Didn't That Work?

When you install Ruby gems that contain native C or C++ extensions (like debase), Ruby doesn't just download a pre-built binary. It actually compiles the raw source code down to machine code directly on your machine so it runs as fast as possible.

While the @development-tools group pulls in a ton of great utilities like git, make, and standard gcc (for C code), it doesn't always explicitly guarantee that the C++ compiler (g++) and Red Hat-specific RPM configuration headers are placed right where Ruby's extconf.rb script is looking for them on a fresh environment.

Without g++ explicitly available in the PATH, the compilation halts immediately.

The Actual Fix

To fix this, I needed to bypass the generic group install and specifically target the C++ toolchain and the Red Hat configuration files that native Ruby extensions rely on.

I ran this command:

sudo dnf install gcc-c++ make redhat-rpm-config

To verify it worked, I double-checked that my shell could now see the compiler:


bash
which g++
# Output: /usr/bin/g++

Fixing Low USB-C Audio on Fedora Linux: My Battle with the Razer Leviathan

Daniel — Sun, 16 Aug 2026 19:35:00 +0000

TL;DR: If you have a Razer Leviathan connected via USB-C on Linux and the volume is incredibly quiet even at 100%, PipeWire is likely crushing your ALSA hardware baseline on boot. Just paste this script into your terminal to automatically fix it every time you log in:

# 1. Create the necessary directories
mkdir -p ~/.local/bin
mkdir -p ~/.config/autostart

# 2. Write the volume-fixing script
cat << 'EOF' > ~/.local/bin/fix-razer.sh
#!/bin/bash
# Wait for PipeWire to finish initializing
sleep 3

# Dynamically find the Leviathan's ALSA card ID
CARD=$(awk '/Leviathan/ {print $1}' /proc/asound/cards | head -n1)

if [ -n "$CARD" ]; then
    # Find the exact name of the volume control (e.g., 'PCM' or 'Speaker')
    CTRL=$(amixer -c $CARD scontrols | awk -F"'" 'NR==1 {print $2}')
    # Max out the hardware baseline
    amixer -c $CARD sset "$CTRL" 100%
fi
EOF

# 3. Make the script executable
chmod +x ~/.local/bin/fix-razer.sh

# 4. Create the desktop autostart entry
cat << EOF > ~/.config/autostart/razer-volume.desktop
[Desktop Entry]
Type=Application
Exec=$HOME/.local/bin/fix-razer.sh
Hidden=false
NoDisplay=false
X-GNOME-Autostart-enabled=true
Name=Fix Razer Volume
Comment=Max out Leviathan hardware volume on boot
EOF

The Struggle: New Hardware Meets Linux Audio

I recently picked up a Razer Leviathan speaker and plugged it right into my Fedora Linux machine via USB-C. I expected it to just work. At first glance, it seemed perfectly integrated: pressing the physical volume buttons on the Leviathan actually moved the volume slider on my screen.

But there was one massive problem: even with my system volume cranked to 100%, the audio was basically a whisper.

I knew the USB connection was passing a pristine digital signal, so it wasn't a degraded cable issue. Instead, I had stumbled into the classic Linux audio tug-of-war between low-level drivers and modern session managers.

The First Clue: Uncovering the Double Volume Limit

In Linux, there are often two volume limits happening at once when dealing with USB audio gear: a software limit (what you see on your desktop) and a hardware limit (controlled deep in the system).

I opened my terminal and fired up alsamixer, the low-level audio interface. Sure enough, when I selected the Razer Leviathan, I found a hidden volume slider sitting at the bottom. By pushing that slider to 100, the room-shaking volume instantly returned. My desktop slider and the speaker were finally synced.

Problem solved, right?

Not quite.

The Amnesia Problem: Fighting Reboots and Sleep States

Every time I restarted my Fedora machine, or even if the speaker just went to sleep and woke back up, the volume would plummet back to a whisper. It was infuriating. Linux was treating the speaker as a brand-new device every time it initialized, dropping the hardware floor back down to its ultra-quiet default.

Here is a quick rundown of all the things I tried that completely failed:

sudo alsactl store: I tried saving the ALSA state permanently. It worked until a reboot, at which point modern Linux audio demons intervened.
Writing rigid udev rules: I grabbed the vendor and product ID (1532:054a) and wrote a strict kernel rule to force the ALSA volume to 100% the millisecond the device reconnected. But it still got steamrolled.
The PipeWire Soft-Mixer Hack: I learned that WirePlumber (PipeWire's session manager) was loading after my udev rules, misinterpreting the Leviathan's hardware volume curve, and aggressively crushing the sound. I wrote a custom wireplumber.conf.d rule to force a "soft-mixer" and ignore hardware decibel limits. That severed the connection entirely, locking the speaker at its low boot volume permanently.

The Winning Solution: The Delayed Autostart Script

The core issue was a timing conflict. PipeWire needed to finish booting up and applying its broken hardware limits before I could safely override them.

I realized I needed a script that could dynamically find the speaker, identify its ALSA control name, and push it to 100%—but it had to run automatically, slightly delayed, every time I logged in.

That's where the TL;DR script at the top of this post comes in.

It drops a tiny bash script (fix-razer.sh) into your ~/.local/bin/ folder. The magic is in the sleep 3 command at the start, which gives PipeWire enough time to completely initialize and settle. Then, the script uses awk to dynamically hunt down the Razer Leviathan's current USB card ID, finds the correct volume channel name, and uses amixer to force the hardware baseline to 100%.

Finally, it creates a .desktop autostart entry so the GNOME/desktop environment triggers the script silently in the background right after login.

No more manual terminal tweaking. No more whisper-quiet YouTube videos. Just booming sound every time I boot up Fedora.