1

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

    etc.

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.

4
  • 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

2

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.

2
  • 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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .