Skip to main content
Unix & Linux

Return to Question

Edit to address cas's answer
Source Link
PCaetano
PCaetano
  • 113
  • 4

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.

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.

Source Link
PCaetano
PCaetano
  • 113
  • 4

Building a custom development environment

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.

  1. 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.

  1. 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.