I'm building a system, mostly for educational purposes, not just for the building process itself, but also for development/debugging.

This is what I would like to achieve.

  1. Install a toolchain that's completely independent of the system toolchain.

    1.1. GCC (C, C++) is a must. I want to keep the compilers isolated from the OS (e.g., to upgrade when I deem necessary), and also for building libstdc++ debug/release, both with debug symbols and source. "Isolated" also means I'd prefer GCC not to contain the usual hard-coded paths. The current system GCC is 5.1.1, I would build 5.2.0.

    1.2. libc/glibc would be a nice-to-have, for the same two reasons above. Is it advisable? I'd probably use the same version as that installed on the system.

    1.3. make/binutils. Is it required/advisable? I'd probably use the same versions as those installed on the system.

  2. Build from source some libraries/tools I use more often, such as:

    2.1. zlib

    2.2. ICU

    2.3. OpenSSL

    2.4. Boost

    2.5. Qt


I build these from source, again, because I like to build debug/release versions of each, linked with debug/release versions of other built-from-source dependencies (e.g., Boost -> ICU), with debug symbols and source for all. And also because I like to experiment with different configure options.

  1. For other libraries/tools, use the packages from the system repos.

    3.1. This includes requirements for the libraries above - e.g., libxbc, libgstreamer, or dbus for Qt.

  2. Even though I do have root access (this is a Fedora VM on VirtualBox), I'd prefer to do without it.

I've looked at Linux From Scratch and, while there's plenty of useful information for what I intend to do, there is, I believe, a fundamental difference, in that I don't want something that's completely separated from the "host" system. I want my tools/libraries always to search my installation paths before the system's, but otherwise have access to everything else installed from the repos. I also don't want to remove any system tools (e.g., GCC/binutils) and libraries (I believe the system should use its own libc or OpenSSL, rather than mine). If the system needs to build something, it should not find my tools/libraries.

  1. My questions.

    5.1. As stated in 1.3, above, should I use the system's make/binutils, or do I need to build my own from source?

    5.2. Given my requirement of having access to the "host" system, is a chroot environment feasible/desirable?

    5.3. Is there anything else I should look into before I begin doing this?

I'll admit up-front I'm a bit out of my depth, but that's how I've always learnt everything, so that's not a problem.

Any help/suggestion/pointer to relevant documentation is most welcome.

Edit to address cas's answer

My goal is not bleeding edge, but control over debug versions. I can't find a debug (non-optimized) version of libstdc++ (obtained by configuring GCC with --enable-libstdcxx-debug), on the Fedora repos. If I had this on a package, I wouldn't need to build GCC from source.

And, even though learning more about the build process and its interaction with the system components is a bonus, what I really want is to experiment with GDB, symbol-loading, and debugging optimized vs. non-optimized code. That's why I'd like to have the non-optimized versions of the libraries.

I agree on the trouble. My previous 2 attempts, where I followed the "normal" way you mention, have resulted in unusual errors building Qt (the most complex software I expect to build from source); and, when building with the "system toolchain", everything went fine. Which is why I thought that maybe there was a better way to do I want, more thorough, but without requiring building the whole system from source.

I can move to a different distro, provided I don't have to build everything from source, and I have no requirement on software versions, i.e., I could build GCC 5.1.1, which is the same I have on my Fedora VM, to minimize the differences. I'm already following the "build recipes" from Fedora packages as much as possible.

  • 1
    Most, if not all, lib packages in Debian come as both -dev and -dbg versions. e.g. package zlib1g (runtime shared libs) has zlib1g-dev (dev files) and zlib1g-dbg (dev files, with debugging symbols). libstdc++ and various qt libs and boost and many others i (very briefly) checked all come with -dbg debugging versions of the packages. all up, in debian sid, there are 2801 packages with -dbg versions (compared to 5734 -dev packages)
    – cas
    Nov 16, 2015 at 20:29
  • @cas Usually those packages (-dev, -dbg) are relative to the lib package, which is an optimized build. The rules file for the zlib1g .deb includes this: ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS))) CFLAGS += -O0 else CFLAGS += -O3, which means it builds either one or the other. However, looking at the .deb binary package for GCC, there is a debug directory, with a libstdc++.so. I'll set up a Debian VM and take a better look at this. If it does include the non-optimized build, I can experiment on Debian, as it means I won't need to build GCC from source.
    – PCaetano
    Nov 17, 2015 at 10:57
  • you can always rebuild the lib, -dev, -dbg packages with whatever compile-time options you choose. as a general rule, it is almost always better to rebuild a package than to compile something into /usr/local or your home dir.
    – cas
    Nov 17, 2015 at 11:04
  • After setting up a Debian VM and installing the GCC -dev and dbg packages, I could confirm it includes both versions of libstdc++ (optimized and non-optimized). I'll try this on Debian, then.
    – PCaetano
    Nov 17, 2015 at 17:18

1 Answer 1


The "normal" way to do this is by modifying the environment of your user to use your compiled versions - e.g. PATH, LD_LIBRARY_PATH, C_INCLUDE_PATH, CPLUS_INCLUDE_PATH etc.

Set these and any other relevant variables in your login script (e.g. ~/.profile for bash or sh).

Then, for example, compile gcc 5.20 using the system gcc and install it under your home directory (e.g. binaries in ~/bin, headers in ~/include, libs in ~/lib etc).

Do the same for other libs / programs you want to compile.

Note, however, that there's no guarantee of compatibility with the system libs - e.g. if you compile an app against a new version of Qt, it may not run correctly (or at all) on your system's KDE/Qt.

Personally, I think you're just making trouble for yourself...the greater the deviation from the system, the more hassle you will inevitably experience and the more you end up with a system that can not be reproduced or understood well enough to be debugged. You'd be better off re-compiling only what you absolutely cannot do without, and even then you'd be much better off if you just compiled a new package to install into the system with the system's package management tools (rpm in your case)

If you really need 'bleeding edge' versions of stuff, then use a bleeding-edge alpha pre-release distro such as Fedora Rawhide or Debian Sid.

  • ps: i don't know what Fedora does with gcc but Debian manages to have multiple versions of gcc installed at the same time, and you can select which one you want at compile-time. You may want to either switch to debian and copy what they do for your self-compiled gcc, or just copy what they do on fedora (if that's possible).
    – cas
    Nov 15, 2015 at 22:42
  • I'll edit my question to address your points. I tried to do it here in a comment, but I kept having to rewrite to the point that some of the sentences were not clear anymore.
    – PCaetano
    Nov 16, 2015 at 12:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.